<< - 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
