Re: Development area?

>From: Paul@ecles.demon.co.uk (Paul Eccleston) >Subject: Development area? >Date: Thu, 4 Aug 1994 22:02:37 +0000 >X-Informix-List-Id: <news.8028> > >Some background:- > > We are using Informix 4gl version 4 on a IBM RS6000. We are also >using a stock control package in which the data files are C-ISAM >(ie we can access them with Informix). > >We have the following directories:- > /u/cham - The stock control packages' data files (LIVE) > /u/chamdev - The stock control packages' data files (DEVELOPMENT) > /u/informix/cham.dbs - The informix database for the live system > /u/informix/develop.dbs - The informix database for the demo system > >We manipulate the SYSTABLES table so that for example, when we access the >stock file, Informix will use the file /u/cham/stock.dat if we are using >the live database, or /u/chamdev/stock.dat if using the development area. > >(I CONGRATULATE YOU IF YOU'VE GOT THIS FAR WITHOUT FALLING ASLEEP!!!) > >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. 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. Note that both techniques are vulnerable to discrepancies in the schema of the two databases. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>