Larry,
I'm not really interested in trying to do version control in the database - we have four developers spread over two states and five major sites that run the code. I don't want that headache. We use MS VSS for our central repository, so I'm happy to have the version control done there. However the version number in the table structure below should be useful to us for comparing code in various copies of the database. Clearly this method will require building some tools to load and unload the code, move between databases, etc. I seem to recall calculating at one point that our app had over 200,000 lines of code, but that was not later than 6.5, and only looked at our main application. 7.x has given us tools to vastly reduce the line count, but there's still a lot of code that I don't think should burden menu forms, reports, etc. RUN SELECT seems like a perfect solution to the issue, and I thank you for whatever role you may have played in its implementation. I've created one form so far where all the eep code is contained in custom form actions, and the form starts off with one variable radio group, two labels, one button and two speed buttons (one to exit the form and one to print the screen.) All the other objects are created dynamically (or destroyed) as required. I can report that it is a bit of work to get there, but once done, a very nice result. That said, a menu that profiles itself to the user is certainly achievable. I've been having a debate with myself over whether to move in that direction, or to go to EFFs for menus. Using EFFs, where do you get the user security data? (One possible answer: a security database .) So many features, so little time! 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 Lawrence Lustig Sent: Thursday, January 03, 2008 1:14 PM To: RBASE-L Mailing List Subject: [RBASE-L] - RE: storing code in the database << - 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) >> Emmitt: I originally requested the RUN SELECT functionality way, way, way back in RBDos days when there was no way at all of storing code in the database (short of sticking it in a NOTE field and unloading it yourself preparatory to running it). My goal was to build my own menu / permissions system in which I only had to update the rows in the code table and some accompanying access control lists and then use a common, unchanging piece of code to present that data to the user as an application. In my opinion the need for RUN SELECT has been eliminated for almost all cases by all the new features of R:Base. However, it sounds like you want to take things further than R:Base currently does by essentially turning your RUN SELECT system into a version control management system (you could even keep older versions of each procedure on line if you wanted to). My original idea was to use CHOOSE to display menus to the user showing only the commands that the user was permitted to see. With the new R:Base functionality to create objects at runtime, I imagine you could easily have each form create a customized version of a menu or group bar from data in the procedures table based on the current user login and other information. That would be very cool -- menus and forms that automatically adjusted themselves to the user's identity! If you go this route, it would be _very_ nice if you submitted an enhancement request for a new kind of rich text editing control -- one that would act exactly like RBEDIT. Then you could _really_ build a version control system on top of R:Base. -- Larry
