RE: Dynamic DATABASE statement

hang on a bit. I don't understand how this works. 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. 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. As for the forms, these can all be changed to FORMONLY so that they can also be database independent. What have I mis-understood ???? You are gonna tell me I'm being stupid aren't you ??? ;-> Seems a complicated way of doing running a single executable against a variety of databases. -----Original Message----- From: Paul watson [mailto:watsop@russellcorp.co.uk] Sent: Tuesday, October 19, 1999 11:35 AM To: batonnet@phase4.com.au Cc: informix-list@iiug.org Subject: Re: Dynamic DATABASE statement Assuming you have some sort of version control in place, I use SCCS, then it's relatively straightforward to do this based on the version number and a decent makefile. But at first glance what you suggest will work. Paul Watson WF Software Ltd Tel: +44 1436 674729 Fax: +44 1436 678729 www.wfsoftware.com/informix # If you broke it, hide the evidence >

> 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. Imagine two databases having the same column in the same table using different datatypes (char - varchar, int smallint whatsoever). That wouldn't produce errors during compile time but IS database-dependant. I think Bryans way will work (used it for myself some time ago) Chris

In article <380CA2D7.455B0D05@Dresdner-Bank.com>, Christian Brauer <Christian.Brauer@Dresdner-Bank.com> writes >> 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. > >Imagine two databases having the same column in the same table using >different datatypes (char - varchar, int smallint whatsoever). > IF 4gl program thinks it is a varchar and the database is a char then the code still works since all varchar(x)'s can be stored in char(x). If 4gl program thinks it is a smallint and the database is an integer then the code still works since all smallints can be stored in integers. In predicate calculus + set theoy... For all x in the set of varchars of length y x is a member of the set of all chars of length y. For all s in the set of smallint's s is a member of the set of all integers. NOTE THE REVERSE IF NOT TRUE. Yes, I'm a Comp. Sci. graduate... >That wouldn't produce errors during compile time but IS >database-dependant. > > >I think Bryans way will work (used it for myself some time ago) > >Chris -- David Williams