I'm given to understand that code stored in forms is now run from memory, not a temp file. I don't have any insight on RUN SELECT.
Emmitt Dove Manager, DairyPak Business Systems Blue Ridge Paper Products, Inc. [EMAIL PROTECTED] [EMAIL PROTECTED] (203) 643-8022 -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of MikeB Sent: Thursday, January 03, 2008 11:37 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: storing code in the database Maybe... The Run Selects create a temporary file that is executed. I don't know if this action is committed to an in Memory file like form code or not. Razzak would have to speak to this. It is likely that when that change was made, that all code passing through the parser was handled the same way, but pause for a short time for the answer... ----- Original Message ----- From: "Charles Parks" <[EMAIL PROTECTED]> To: "RBASE-L Mailing List" <[email protected]> Sent: Thursday, January 03, 2008 11:27 AM Subject: [RBASE-L] - RE: storing code in the database Is there any savings in time\execution between code executed in "run select", stored procedure, stored as Form Action, directly in a component, external file, etc. I have been placing the code directly into form actions so as a form is changed in a test database and ready to be moved to a production database everything is in the form instead of having to find code located elsewhere along with the form. Is this the better way to do this or should the code be stored in the database separate from the form for better time\execution speeds? -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of MikeB Posted At: Thursday, January 03, 2008 10:16 AM Posted To: RB7-L Conversation: [RBASE-L] - RE: storing code in the database Subject: [RBASE-L] - RE: storing code in the database > > I want to move all disk-based code into the forms/reports/database so > all that is required on disk is a startup file. Yes, we could > compile, but as we have to access the app from multiple versions of > R:BASE, I want to delay that. Even compiled, I like the ability to > change code without having to recompile. > Also, it is pretty easy to create your own application to automate the any changs to the stored command files from disk, and also you are still permitted to trace the stored file, BelieveItOrNot.... stand alone: trace select cmddata from intcmd wher cmdname = 'msgbox' and when it is inline it will still trace OK. The RTeam fixed this a couple years back.... Thank Them Very Much! > > Emmitt Dove > > Manager, DairyPak Business Systems > > Blue Ridge Paper Products, Inc. > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > (203) 643-8022 > > > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Jeffrey M. > Watson > Sent: Thursday, January 03, 2008 10:47 AM > To: RBASE-L Mailing List > Subject: [RBASE-L] - RE: storing code in the database > > > > Emmitt I would imagine the best way would be to incorporate those on-disk > files as stored procedures or if they are only used local to one form, as a > form action. But you know your needs best, perhaps you have a reason to want > to do it this way? > > > > Jeff Watson [EMAIL PROTECTED] > Tube Methods, Inc. > 610-279-7700 > > > > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Emmitt Dove > Sent: Thursday, January 03, 2008 10:43 AM > To: RBASE-L Mailing List > Subject: [RBASE-L] - storing code in the database > > > > Has anyone undertaken a large-scale effort to store code in the database? > Not the code in forms or eeps, but command file code that otherwise would > reside on disk, and when stored in a table is executed with a RUN SELECT . > > > > I'm particularly interested in your table structure to accomplish this. > > > > Emmitt Dove > > Manager, DairyPak Business Systems > > Blue Ridge Paper Products, Inc. > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > (203) 643-8022 > > > >
