Dynamic DATABASE statement

I have a requirement to run 4GL code against multiple databases within the same IDS 7.3 instance. This is a classic set of production, QA and test databases. Basically, I want to use the same 7.2 4GL to compile and run across all these databases (not at the same time) with no changes to the 4GL code, which contains a lot of records LIKE tables and variables LIKE fields. I understand the uses of the DATABASE statement within and outside the MAIN function. Thinking this would be well covered in the FAQ and here in c.d.i, I turned first to these trusted resources. Lots of info in here, but it all seemed to assume that the database structures were the same, so that the compile time DATABASE statement would work, and then the dynamic DATABASE statement picks up the runtime database as required from the environment. For me, this won't work as the schemas of these databases are rarely going to be the same, and it certainly is not guaranteed at any point in time. In any case I have inherited .per files with explicit DATABASE statements which are not covered by the suggestions of the past. Surprisingly no-one seems to have expressed this previously, and I found no mention of any other solutions here or in the FAQ. Seeing as how I had pretty much made up my mind how I was going to tackle this, I became immediately nervous when the wizards of c.d.i had not mentioned my solution in about 4 years of postings. So, at the risk of being dumb (but that's better than wasting a few weeks of effort), what's wrong with this crude scheme; Strip out any "top of module" DATABASE statements from .per or .4gl Set $DBNAME to suit your current operational mode Then, at compile time; ext=$$ mv source-file source-file.$ext echo $DBNAME > source-file cat source-file.$ext >> source-file fglpc (or form4gl) source-file mv source-file.$ext source-file OK, so fgldb will complain, but that's easily circumvented. Other than that, this would be easy to build into a Makefile or a stand apart script, and in rudimentary testing, seemed to do the job. I get the feeling I'm missing something simple, so I await your critisism. Bryan Tonnet bryan@printman.com.au