Re: Dynamic DATABASE statement

> Surely if you have variables defined 'LIKE' tablename.column name then > changing the DATABASE statement at the top of your 4gl will produce errors > at > compile time if the structures of your databases are different. > > The only way that would work is if some of the database tables and/or > columns were same > and that those tables/columns were the ones used for defining variables. If > that was the case then > I still can't see the need for changing the database statements at the top > of your 4gl's because the > programs would then compile against any one of your databases. But not necessarily. E.g. a field is added to the table tab_name in the test database. The 4GL contains; DEFINE tab_rec LIKE tab_name.* This will compile OK regardless of which database is listed at the top of the 4GL (all databases have a table called tab_name), but tab_rec is a different record structure depending on which compile time database is used. > You could then change the DATABASE that your program runs against by either > passing in the database name at > run time or by setting and environment variable which would be 'read' by > FGL_GETENV at run time. Yep. It's a good method if you have no compile issues. I assume there's some deep technical reason why Informix have never implemented fglpc -d <database> (for RDS compiles), as this would make enormous sense and neatly get around the whole issue. > As for the forms, these can all be changed to FORMONLY so that they can also > be database independent. True enough, but this obviously involves signifigant work where field tags are inheriting the data types, attributes and whatnot of the database columns. To add all these to a few hundred forms will be tedious to say the least. Me, I'll take the lazy way out if I can get away with it :) Bryan Tonnet