Re: SET UP TESTING DATABASE

pencoke wrote: > M MI upgrade from informix 4.0 to J7.272UC7. In our old version, > we had two data base using same name i.e. \\real\\compdata > (compdata.dbs) and \\test\\compdata (compdata.dbs). OK, so you used to be using SE. > The purpose is that we could run same 4gl in real or test environment. > What we need to do is to set in DBPATH in .profile (IBM UNIX AIX). > While DBPATH=...\\real\\compdata , all 4gl will be automatically call > the real database. If setting DBPATH=...\\test\\compdata, all 4gl will > automatically call the test database. We found it very useful as no > amend in 4gl is needed. Yes, it was useful. > However, in version 6.0, we can not set up something like that. > There is no DBPATH setting. If we want to have such setting for > test and real environment in same UNIX machine. > > 1) Do you know the configure or what we need to do. > 2) all database file in version 4.0 can be view from ls -l in the > directory. But we can't see in version 6.0 using ls -l . Do you > know if we can view tables in file system. Answering Q2 first, I take it that you must be using OnLine now. If you were still using SE, then you would still be able to connect to different versions of the database using DBPATH, and you'd be able to see the files as before. With OnLine, the rules of the game are somewhat different. You have two main options: 1. Run two instances of OnLine on your machine, one for production work, and the other for test work. These instances would be accessed by setting the INFORMIXSERVER variable to different values. The great merit of this approach is that it requires no code changes in the program source. The great demerit is that it requires two lots of OnLine eating up system resources, and adding a QA database to the list of requirements adds a third OnLine system, quickly making it unwieldy. 2. Arrange for your programs to connect to an arbitrary database at runtime, based on some suitable configuration parameter (I normally use an environment variable). You are then faced with 3 issues: * which database do you compile with, and * how to avoid connecting to the default database at startup, * how to connect to the correct database at startup. The answer to the first problem is simple: you compile against the database with the same name as is currently in the source code. That requires no source code change. The answer to the second problem is less simple; probably the best way to handle it is to change the existing source files which contain MAIN ... END MAIN so that they contain a function instead: FUNCTION i4gl_main() ... END FUNCTION. You have to remove any DEFER INTERRUPT or DEFER QUIT calls because they can only appear in MAIN ... END MAIN. You then create a simple file which contains just: MAIN DEFER INTERRUPT DEFER QUIT CALL set_database() CALL i4gl_main() EXIT PROGRAM 0 END MAIN Note that there is no database statement explicitly in this file; that prevents any database being opened automatically. The function set_database() arranges to find the name of the correct database and opens it -- and fails to return if it fails to do so. You then revise the linking process to pull in the new file with MAIN (presumably main.o or main.4go, compiled from main.4gl) and the set_database function. If you've got a project library, of course, that isn't any problem -- if you haven't, now might be a good time to create one. As long as the database chosen at runtime has the same structure as the one used at compile time, this system works very well. And it scales to handle as many different categories of databases (mine, yours, QAs, production, production in the newly acquired subsidiary, the ne developer, an obstinate manager, ...) as you need. They do not have to reside on the same machine, but they may. They do not have to reside in the same OnLine instance, but they may. Oh, and the technique can be used with SE too. I wonder when I last gave this spiel -- probably not in the last year and a half, but the subject has certainly been raised before and I've proposed substantially the same answer before. Yours, Jonathan Leffler (j.leffler@acm.org aka jleffler@earthlink.net) #include <too-many-aliases.h> #include <guardian-of-DBD::Informix.h> #include <disclaimer.h> #include <witticism.h>