Re: Development area?

} >Question:- } > This setup works quite well, except for the fact that once a } >program is ready to be put live, we need to alter the database to be } >/u/informix/cham.dbs and then re-compile all the modules, alternativly } >if we want to play with a program which is live, we need to alter the } >database back to /u/informix/develop.dbs and re-compile again. } > } >Is there anyway that the database does not need to be specified until } >runtime? } >We've attempted to set an enviroment variable called DATABASE and used the } >following code in Informix:- } > } > database "$DATABASE" } > } >But this doesn't work. } > } >Has anybody any suggestions, on how we can simply this procedure. } } There at least two possible ways of dealing with this. } } Technique A: } Use the same database name for both live and development work. This } requires the databases to be in two different directories -- eg: } /u/informix/test/cham.dbs } /u/informix/live/cham.dbs } and then you can use both the source and object code unchanged, using the } DBPATH environment variable to pick up the correct database. } } Pro: Simple, easy. } Con: Not as reliable if programmers have access perms on live database, } because they can end up modifying the wrong database if the } environment variable is not set correctly. } Con: Cannot be used with OnLine. Hey, what if you just have another instance of OnLine, and you select one of them using SQLTURBO environment variable, or something, I don't remember off top of my head, but it is possible to have two instances of OnLine running, one serving the 'live' partition, and the another one serving the 'test' partition. } Technique B: } Compile all modules against one of the two databases -- it doesn't matter } which as long they are the same. Then, either revise the code so that the } MAIN programs are in micro-modules which simply contain: } } MAIN } DEFER INTERRUPT } DEFER QUIT } CALL choosedb() } CALL realwork() } END MAIN } } with no database statement at all. The library function (which you write) } called choosedb() determines which database to open based on any } environment variable you care to decide on, and opens it. It can also be } used to do any other standard setup work except DEFER operations -- those } can only occur in MAIN. This micro-module is then compiled and linked to } build the application. It is only MAIN that gets an implicit DATABASE } statement created in it when you use the non-procedural DATABASE statement, } the one which enables you to write: } } DECLARE r RECORD LIKE Table.* } } Pro: Comprehensive } Pro: Work with OnLine } Pro: Adaptable } Con: Requires more major code changes. Could be done in a script, which can also set up some environment variables. We have two '4gl application startup scripts' - first one presents a menu, and the second one is for running in the background via cron. I like to have users go through the script to get to the 4gl application. If I do not have to do any clean up at end of the script, I just put in 'exec <4gl application>' so I wont have /bin/sh sitting around waiting for the 4gl application to exit. } Note that both techniques are vulnerable to discrepancies in the schema of } the two databases. Hear, hear ! Another idea is to have a 'configuration' table in the database. The table can be used to hold information, such as where the TMP directory is, and so forth. We have one in our production system. One of the entry in the configuration table can indicate if the database is live. The application, when starting up, can check for this, and put up a box warning the user that he is working with LIVE data. The configuration table also can hold current database 'revision' level, and all 4gl applications check this also, so if they were started accidentally, they will just put up a box stating that they won't work with tables at this revision level, and quit. Just my two cents worth. } Yours, } Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> -- ------------------------------------------------------- | Paul T. Pryor | Computer Data Systems, Inc | | (703) 756-8350 Voice/TDD | Falls Church, VA USA | |-------------------------------------------------------| | ptp@fallschurch-acirs2.army.mil [192.86.95.3] | -------------------------------------------------------