Re: Linking ESQL & 4GL
Posted in 1994
}From: spitz@GANS2X.ana.med.uni-muenchen.de (Richard Spitz) }Subject: Re: Linking ESQL & 4GL }Date: 13 Jul 1994 06:40:09 GMT }X-Informix-List-Id: <news.7574> } }Jonathan Leffler (johnl@informix.com) wrote: }: The key information here is that the I4GL is a 4.1x and the ESQL/C is a }: 5.0x version. This means that I4GL uses a version 4.1x ESQL/C library, }: which is significantly different from the 5.0x library. In particular, the }: mechanisms for handling cursors and statements are quite different at the }: implementation level, and the calls generated for a DECLARE statement, for }: instance, are quite different. Further, the 5.0x library is not a simple }: superset of the 4.1x library -- the two cannot be mixed reliably. }: Typically, the programs won't link at all, either suffering missing or }: duplicated references. However, even if you managed to get them to link, }: the code would be unreliable. Don't try it. } }Does that mean I have no chance carrying over my programs from my old }machine with an all-4.1-environment to my new machine which has ESQL/C }5.01 and I4GL 4.1? } }I've written some programs IN ESQL/C which do most of the database access }and some other stuff which can't be done in 4GL and use 4GL modules only }for screen I/O. Your above statements imply that this code will break }in my new environment. For simplicity and safety, I would suggest retaining the 4.1 ESQL/C. Or use c4gl to compile the 4.1 ESQL/C -- that will work too. However, if you strictly segregate your database access code from the screen I/O code, then there is, in principle, a reasonable chance that things will work OK. I have not tested it; it is not supported; it might work. One thing to beware of: any reports which do ORDER {INTERNAL} BY use a temporary table and SQL to access it -- it would be advisable to keep those clear of the 5.01 ESQL/C. }If I have to rewrite, I have one more concern: Are SQL statements within }a 4GL program just as performant as embedded SQL statements in C? The SQL statements in I4GL are treated identically to the statements in ESQL/C -- indeed, ESQL/C is one of the intermediate languages used in translating I4GL into an executable. That means the performance of the statements is identical. The only problem is that the I4GL compiler thinks in terms of 4.1x ESQL/C rather than 5.0x ESQL/C. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>