Re: How do you choose database at RUNTIME in r4gl?
Posted in 1994
Topics: Installation, Setup & Upgrades, Connectivity: ESQL/C, 4GL & Embedded SQL, Platform-Specific Issues
Micheal W. Lester (mlester@lonestar.utsa.edu) wrote: : SCENERIO: : We have two systems, production and development. : ISTAR is installed on both systems so we can perform remote queries. : We have scores of 4gl reports that share a common 4gl GLOBAL header file. : When we wish to access data that is on production, we change the statement : database lotsadata : to : database lotsadata@production : and recompile the program. When we run the program on development, we will : get production data. : This causes problems because we have several programmers working in : Interactive 4gl (OnLine 4.11 for AIX 3.2.5) and we step on each other. : It is difficult to know where a compiled program will pull its data from : by looking at the P code, and the "database xxxx@yyyyy" statement causes : contention between programmers needing data from development and those : needing to access production. : Is there a way that we can specify the database name at run time, instead : of compile time? Maybe make r4gl look at the contents of a UNIX : environmental variable, DBNAME? The solution posted by Bob Baskett works well, but the 4gl program will still attempt to open the development database, then close it, then open the one specified by the command line arg. This can be a problem if your development database is on one machine, and your production is on another, and the development machine goes down. Your program will stop, as it needs access to your development database due to the default open. I have listed an alternative below which does not open any database, until you tell it to: ______________________________ If you have a "database blah" statement in the same module as your main function, 4gl will try to be helpful and open that database for you. The only reason you would need a database stmt in you main is if you have "define like" stmts, or if you have SQL statements. If you create a main that does not have either of those things, no database will be opened implicitly. You can call another function that contains the database open statement, which will then be under your control. You can still use the name of your development database in your globals file, as it is only needed at compile time. Just remember, if your globals file includes a database stmt, then you can't use in the module that contains your main. The example below is over simplified, but you get the idea. Hope this helps. It works out great for us. I would like to take credit for this insight, but I got the solution from Scott Ellard (Informix Jedi Master). Example: one.4gl main define dbname char(40) let dbname = arg_val(1) call open_db(dbname) call do_normal_pgm_stuff() end main two.4gl globals "globals.4gl" function open_db(dbname) define dbname char(40) database dbname end function globals.4gl database dev_db@devbox globals define fish_rec like tablx.* end globals -- _/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_/\\_ Erik Jones erik@sunnet.chotel.com Staff Antagonist/Database Systems Group Voice: 602 953 4471 Choice Hotels International, Inc. Phoenix AZ