Re: Is there a way of specify database name alias in the same server?

On Wed, 01 Oct 2003 08:38:14 -0400, Mario R. Canto wrote: Mario, if the MAIN contains a DATABASE statement then the DATABASE statement outside MAIN is only used at compile time to resolve data types, column references, etc. If MAIN does not contain a DATABASE statement then the compiler copies the database statement into the main() .ec function that it generates. If you include another DATABASE statement in the MAIN then that will be executed after the one copied from the top of the file and this one can contain a variable whose value you have extracted from a commandline argument or environment variable, so: DATABASE "mydatabase1" MAIN define dbnam char(128) LET dbnam = fgl_getenv( "MYDATABASE" ) DATABASE dbname ... The database mydatabase1 will have to exist at compile-time and if it will not exist at runtime then you will have to include an ON ERROR CONTINUE statement so the database not found error from the first (hidden) DATABASE statement will be ignored. Art S. Kagel Art S. Kagel > Jonathan, and OTC, > I knew that many instances was 'THE' solution to this particular case. Because > the caracteristics of the (relatively small ) develompment server, I cant't > use so many instances (9 or 10). I was dealing with > RENAME DATABASE mydatabase TO mydatabasecompanyN RENAME DATABASE > mydatabasecompany1 TO my database > in dbaccess (didn't test sqlcmd), when I need to switch. I was only looking > for the simpler method to accomplish this. I will take in account your small > MAIN program that selects the correct database. Thank you for your answer > > Mario R. Canto > > > Jonathan Leffler wrote: > >>mcanto@4m.com.ar wrote: >> >> >> >>>Scenario: >>> >>> IDS 9.40 >>> 4GL RDS application >>> Linux Redhat 7.3 >>> A unique database server (INFORMIXSERVER=myserver) >>> >>> 3 datatabases with identical schema in the same server: >>> mydatabasecompany1 >>> mydatabasecompany2 >>> mydatabasecompany3 >>> >>> In the 4GL software there are static DATABASE statements pointing to >>> mydatabase. ie: >>> DATABASE mydatabase >>> >>>Question: >>>Is there a way to define an ALIAS for a database like this >>> ALIAS mydatabasecompany1 AS mydatabase >>>so that I can switch from one to another without changing thousands (OK, >>>hundreds) of programas with static references? >>> >>> >>> >>> >>No, but there's no particular need to do so, either. >> >> >> >> >>>They come from standard engine where I can change easily DBPATH to a >>>directory containing company1/mydatabase or company2/mydatabase >>> >>> >>> >>> >>With multiple instances, as the noble OTC said, you could do it - by simply >>changing the value of INFORMIXSERVER. >> >> >>You do have some standard startup code that you use to do things like start >>log files and validate that the user is permitted to access the database, >>don't you? >> >>If so, you can extend it to switch the database at run time. Ideally, you >>modify the code so that it uses a dummy main program: >> >>MAIN >> DEFER INTERRUPT >> DEFER QUIT >> CALL select_runtime_database() >> CALL real_main_program() >>END MAIN >> >>This, be it noted, does not pre-select any database - that's the job for the >>select_runtime_database() function. The real_main_program() is your current >>code in MAIN/END MAIN modified so it starts FUNCTION real_main_program() and >>ends with END FUNCTION, and you also remove any DEFER INTERRUPT and DEFER QUIT >>statements. That can be done by a sed script, let alone a Perl script (which >>is what I'd probably use). >> >>You have to be confident that the 'mydatabase' which is used at compile time >>has the same structure as the operational databases. If you get that wrong, >>you will have (if you're lucky) fatal runtime errors (and if you're unlucky, >>weird corruption problems caused by modifying the wrong data). >> >>If you don't already have the standard startup code in place, now might be a >>very good time to add it - it is one of the things that can really save your >>bacon when migrating from SE to OnLine/IDS/XPS. >> >>See also my postings on this subject from a year to ten years ago, maybe even >>longer since the first one. >> >> >> >> >> > sending to informix-list