Re: DB Definition Reference

Mark R. Ainis, molten keyboard in hand, chimes in with: > We have an application that consists of Informix 4gl programs on our HP > machine. In all of the source codes, we have record declarations that > reference current database table definitions using the LIKE key word. > A sample of the source codes is attached below. The problem arises > during compiling. The compiler must know the database name explicitly > specified in the first line of the codes in order to define the record > definitions. Is there a known way of eliminating the hard-coded > database name in the source such as passing the name to compiler during > compilation? Nope, not the I know of at least. But the question I have is why is this a problem? Is it a problem because you want to have the program RUN against another database? If you only need to RUN against another database, you can have the first line of code open up the database of your choice with the DATABASE statement. For example: DATABASE test DEFINE my_rec LIKE db_rec.*, use_db char(18) MAIN let use_db=ARG_VAL(1) # First command line argument DATABASE use_db etc. etc. etc. END MAIN Works like a champ. However, in the case above, you still need the 'test' database because 4GL will open the database 'test' first thing. You don't need anything IN the database, it just has to exist. Note, however, that if the 4GL file with the MAIN routine does NOT have the 'database test' statement, and does not need to use LIKE and such, then NO database will be opened on execution, and you'll need to do it yourself. So, you could do this: main.4gl: DEFINE use_db char(18) MAIN let use_db=ARG_VAL(1) # First command line argument DATABASE use_db call doit() END MAIN doit.4gl: DATABASE test DEFINE my_rec record like db_rec.* FUNCTION doit() etc. END FUNCTION In this case, you never need 'test' except to compile the modules, you won't need it around to run the programs. If you really have the problem of want to COMPILE against different databases, then Informix does not specifically support this. You could try a couple of things, however. You can have multiple instances of the same database on your system, and compile against the different version as appropiate with judicious application of TBCONFIG or DBPATH or INFORMIXSERVER. We have several instances of Online and SE, all running the same database. We have scripts which do all of the environment mashing for us. Or, if you're really motivated, you can wrap your code into a script that calls either cpp or m4, both are preprocessors. I know some folks in c.d.i use cpp/m4 for their stuff. Or if your system is Tool Challenged, there's always the "Better Living With sed(1)" technique. Just have a convenient master source copy, and bang out some quick compilation scripts to do the work for you. Of course, if you're on NT...well...I'll mention you to the Big Guy this Sunday. For us, it hasn't really been a problem. Well, I guess it has, we've just worked around it. What I'd rather have, though, is a way to alias database names. That would rock and roll for us. > p.s. We called Informix's Tech. Support; however, the only answer we > got from them is: To get rid of the problem, DON'T use it! We are > quite disappointed with Informix's Tech Support. It looks like they > are no better than us. "We kept trying to feed X-Rated GIF files to the 4GL compiler, and it core dumps!!! Informix Tech support was USELESS! They were completely incompetent, and couldn't give us any solutions. I'll never call them AGAIN!" (Lemme add some :-) :-) :-) lest I get grumpy mail...) Got horrible news: They are no better than us. They don't know my applications, they've never worked on my machine, and they aren't familiar with my procedures. What's worse, is that they don't like being sent 10,000 lines of code as an "isolated case" when I encounter a bug^H^H^Hproblem. But, they actually do have a clue about their product. They seem to escalate problems readily if front line support can't handle it, and I've kept them past their bedtime before trying to get problems solved. What they do have that we don't have is the collective wisdom of all of the folks reporting problems about stuff they never even thought about AND they have access to the rocket scientists that actually wrote this stuff. However, the rocket scientists aren't the guys on front line support. They're buried in a back room tweaking, tuning, optimizing, and advancing the database to be the best that it can be. So, when they can't help you on something the system can't do (and they probably DID know that what you wanted wasn't possible), I'd cut 'em some slack. Luck! Will Hartung (villy@collinscomp.com)