Re: How do I rename a database?

This mail has two parts. Part A answers Jim Gordon's message. Part B elaborates on the message sent by Dave Kosenko. ********** * PART A * ********** >From: Jim Gordon <uunet!ssf-sys.DHL.COM!jgordon> >Subject: Re: How do I rename a database? >Message-Id: <9203092229.AA26616@dhlmis.ssf-sys.DHL.COM> >Date: Mon, 9 Mar 92 14:29:45 PST >X-Informix-List-Id: <list.938> > >>In article <1992Mar6.033543.6688@nas.nasa.gov> jcarter@sun204.nas.nasa.gov >>>In article <1992Mar5.213646.14124@cs.odu.edu> bander@oswine.cs.odu.edu >>>>Can I rename a database? >>>I hope someone else has a really nifty solution for you. >> >>The question is not so much "how can I rename a database?" as "How can I use >>a test database and a live database and switch between the two?". >> >>There are two answers, one for Standard Engine, one for OnLine. >> >>STANDARD ENGINE. >>... >>ONLINE >>There is no way to do this except by having two OnLine systems around, >>probably on the same machine. Normally, this means having a small >>configuration (possibly using cooked files to store the database) with >>minimal shared memory for the test system, and a main configuration (with >>a lot of shared memory and raw disks for the database) for the live system. >> >>Is this (or are these) nifty enough? >>------------------------------------------------------------------- >>Jonathan Leffler (johnl@informix.com) #include <disclaimer.h> > >Could I possibly suggest Jonathan that you have a quick look in the >manual :-) RTFM :-)) as I'm not sure what the problem is? I am reasonably au fait with the manual. >You certainly don't need two Online sessions. It depends on the constraints you apply. In the original question, the objective was to use the same database name for both the live and the test system. If that constraint is maintained, then you cannot have both databases in the same OnLine system, as the names of the databases must be unique within a single OnLine system. >As the database statement will take a variable as its parameter what we >do is define an environmental variable called DBID and set it to the name >of the database we wish to access. Then at the start of each program we >have a routine that uses get_env to read DBID into a variable (f_db_name) >and then use: > > database f_db_name > >This works for standard and online engines .03 onwards and as the >program database statement overrides the forms database statement in >both ISQL and I4GL we use any of the database names in the forms. This is correct, but it requires the program to be modified. The solution I proposed works without any code changes. >Cheers - Jim >-------------------------------------------------------------------- >Name: Jim Gordon Internet: jgordon@ssf-sys.DHL.COM >Company: DHL Systems Inc Phone: (415) 358-5911 (Work) >Address: 1700 S. Amphlett Blvd. (415) 882-9728 (Home) > San Mateo, CA 94402 Fax: (415) 571-6429 >-------------------------------------------------------------------- ********** * PART B * ********** Dave Kosenko at Informix sent out some mail about this, and he and I have had a discussion internally about what can and cannot be done with these database statements with variables supplying the database name. The following is a summary of that discussion. Dave's comments are prefixed by '>' marks. > The DATABASE statement in 4gl and esql/c DOES allow for >variables. For example, in the 4gl code fragment: > >DEFINE > dbname CHAR(18) > >DATABASE dbname > >the contents of the variable dbname will be used for the database >statement. In esql/c, you can use: > >$char dbname[18]; > >$database $dbname; > > This would be the preferred method for the original question. >However, with the volume of code it sounds like is there, I gather >this would not be easy to change. No quibbles so far. > One point: if you do use a variable database name, then you >cannot use LIKE clauses in your variable definitions (as it needs >to know what database to use to resolve the definition). This statement needs some qualification. You have to use the non-procedural DATABASE statement (outside any functions) to be able to use LIKE, and you can only specify a literal database name. You also need the named database to be present at compile time. However, the non-procedural DATABASE statement has an extra side-effect, which is that the first statement in MAIN is a procedural DATABASE statement. Now, there are a couple of ways of handling the selection of the database at run time. First, you could use the following code: DATABASE Compile_dbs MAIN CALL select_database() CALL other_work() END MAIN FUNCTION function01() DEFINE thingy RECORD LIKE Thingy.* ... END FUNCTION This starts the program, opens Compile_dbs, and then closes it and opens some other database at run time. The overhead here is that the Compile_dbs must exist at run time, and it is opened unnecessarily. Alternatively, you can create a miniscule module for the MAIN: MAIN CALL select_database() CALL other_work() END This has no DATABASE statement anywhere, nor any other functions. It does not need to refer to any globals either. When this is run, no database is selected automatically because there is no non-procedural DATABASE statement. Everything else can be compiled with reference to Compile_dbs; at run-time, they will actually use whatever database has been selected by the select_database() function. The Compile_dbs does not need to exist at run-time. > You have tested this? I would not have expected that to be true, Yes, often. > but am quite willing to concede defeat in the fact of empirical > evidence. I would have expected that any database referenced > in a database statement to have to be present for the program > to work. No, its all a question of timing. The database in the non-procedural database statement must exist at compile time. The database referenced in any procedural database statements must exist at run time. There is an implicit procedural database statement inserted as the first executable statement of MAIN when there is also a non-procedural database statement in the same file as MAIN. In this case, a database with the name specified in the non-procedural database statement must exist at both compile time and run time. When you call a function, it does not check to see what the current database is. If it did, what would it do? It can't switch databases, because that would blow any transactions out of the way. It can't refuse to work. It just uses the current database. (Of course, if one of the tables the function uses is absent, then it will fail; likewise if the table exists but is sufficiently different from the one it was compiled against. But if the tables have the same structure, there's no problem!) > Anyway, I think my original statement is true