My dislike for stored procedures stems back to the early days when it was a pain to create and modify them (remember the PUT and SET LOCK?)
So the "run select" just seemed so much easier when they were first introduced. At this point, I only use stored procedures if I have a Trigger. Otherwise, not a single SP Karen -----Original Message----- From: Albert <[email protected]> To: karentellef <[email protected]> Sent: Tue, Aug 25, 2015 10:28 am Subject: [RBASE-L] - RE: RUN SELECT or Stored Procedure? Thanks, Buddy - I'm still confused, though. A Stored Procedure only runs when you CALL it. I'm still foggy on the distinction between these two command lines anywhere in my code: RUN SELECT CodeBlock FROM CodeBase WHERE CodeBaseName = 'PaymentTotalsUpdate' AND PKNumber = .vInvNo CALL PaymentTotalsUpdate (.vInvNo) Albert On 2015-08-25 9:21 AM, Buddy Walker wrote: Albert the way I think about it is, RUN SELECT is when I want to use it and a Stored Procedure is used all the time. Buddy From: [email protected] [mailto:[email protected]] On Behalf Of Albert Sent: Tuesday, August 25, 2015 11:13 AM To: [email protected] Subject: [RBASE-L] - RUN SELECT or Stored Procedure? Glad that the RUN SELECT worked for you! My head cannot get itself around any difference between a RUN SELECT and a Stored Procedure. Has anyone any idea when one is better than the other? Albert On 2015-08-25 8:06 AM, [email protected] wrote: CFA was for Custom Form Action. It is not related to compiling. You can look in help under CUSTOM and see the options for Custom Form Actions. A CFA is basically an stored EEP that one can access multiple times from multiple places in a form without duplicating the code lines. One could also think of it as a stored procedure that is related only to the current form. The CFA is called with the PROPERTY command such as : PROPERTY RBASE_FORM_ACTION <CustomFormActionCommandName> <parameters> It is a very handy tool so one can avoid duplicating code in multiple locations. This way, when the code does need changed, you only have to change it in one location, -Bob From: "Dan Goldberg" <[email protected]> To: "ttc inc" <[email protected]> Sent: Tuesday, August 25, 2015 8:26:40 AM Subject: [RBASE-L] - Re: Button EEP versus Timer EEP Is a CFA a compiled form application? What was the property command? Just want to make sure I note this in the future. Thx Dan Goldberg From: [email protected] [mailto:[email protected]] On Behalf Of Karen Tellef Sent: Tuesday, August 25, 2015 5:57 AM To: Dan Goldberg Subject: [RBASE-L] - Re: Button EEP versus Timer EEP Big High Five from over here!!! Glad it worked! Karen -----Original Message----- From: ttc.inc <[email protected]> To: karentellef <[email protected]> Sent: Tue, Aug 25, 2015 6:53 am Subject: [RBASE-L] - Re: Button EEP versus Timer EEP I changed the code from a CFA to a Run Select and everything ran perfectly last night. I did a cut and paste of the code into the VarChar column, so there were no changes in the operating code at all. Replaced the Property command with a Run Select and this morning all was good. Not sure what the difference is. I have in the past and have now, other apps that use the form timer eep and CFA,s and they do not seem to have any issue. However, those CFA's have 1/4 the lines of code and no Delcare / While statements. Perhaps a connection? Truthfully, I assumed that a CFA was pretty much a Run Select command just build into the form designer. Thanks to all who submitted ideas. -Bob From: "MikeB" <[email protected]> To: "ttc inc" <[email protected]> Sent: Monday, August 24, 2015 2:03:19 PM Subject: [RBASE-L] - Re: Button EEP versus Timer EEP Let's wait to see what happens with the Run Select before jumping out of the boat. > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Karen > Tellef > Sent: Monday, August 24, 2015 2:10 PM > To: [email protected] > Subject: [RBASE-L] - Re: Button EEP versus Timer EEP > > Javier: I've seen Bob's app before, and it's a cool front-end type of > form with lots of data for the users to see. The timer updates some of > the data on the form. > Let me think, if a scheduled task ran an "outside" RBase program, I > guess it's possible that that program could dump the display data into > a lookup type of table, and could still have a timer on the form that > would gather and recalc the > display. The form could have a "date last ran" / "date next run" so > the user has > some feedback on the process. A bit of work, but it would take the > form out of the equation, wouldn't it? > > > Karen > >
