Jeffrey,
We make extensive use of Stored Procedures already. Here's my vision: - Any code related to a form is stored in the form - Any necessary eep code for reports is clearly stored within the report - Stored procedures hold the equivalent of user-defined functions and code for triggers - All other code is stored in a code table Examples of the "all other code" would include the code written that runs before a form is loaded, that accomplishes some task that involves neither a form or a report, or that ultimately results in a report being printed. In a typical report command file now we: - Check security to see if the user can access the report - Get input values, such as dates, customer numbers, etc., that will limit the results - Build temp tables and/or views as necessary for the report, load the data - Print the report As some of our reports are very complex or the result of complex calculations, our command file code may contain multiple cursors that load/analyze/summarize the data prior to printing the report, and can run hundreds of lines of code. The same code may be used in front of multiple report formats (varying levels of summary/detail) so one of the selections may be which report to run. This doesn't meet my definition of a stored procedure, though it likely could be done that way. The table structure I envision would contain: - Process name (PK) - Disk filename (for auto loading and unloading) - d/t created - author - d/t last revised - revised by - version number - comment - code column (varchar datatype) As you can see, this goes beyond what can be tagged to a stored procedure. As a side note, we now have a folder where the stored procedure code files are kept, and we have a part of our rebuild process which can drop and put all the procedures to assure we have the latest version installed. In the case of storing all the code in the database, I might go so far as to store the stored procedure code in my code table so I can re-put the procedures if required. This would involve (I think) writing the code to disk then PUTting from there, but it may be very useful. In that case, I may want to add a column to my code table to indicate the *type* of code it is (i.e., stored procedure, view definition, process code, etc.) 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 11:09 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: storing code in the database stored procedures have nothing to do with whether or not your code is compiled. I really think as long as you are not using the restricted commands that Mike B made reference to, the best solution would be to use a stored procedure. You would just make a new stored procedure and feed it the path of your command file, and then it is stored in the database for you, and instead of using run to execute the command file you use call to execute your internally stored command file. check out the stored procedures and call in the help files. 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 11:04 AM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: storing code in the database Jeffrey, 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. 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
