Re: Valid combinations of ESQL and Online?

Ouch! I've put some detailed No answers into the start of this message, and the tail has some reasonably accurate interworking guidelines. >From: czahl@cs.tu-berlin.de (Christian Zahl) >Date: 8 Jan 1996 12:06:36 GMT >X-Informix-List-Id: <news.20110> > >I have a stupid question, but the answer is needed to make a precise >decission. > >Which ESQL and 4GL versions are working with which Online versions? >Or more specially, can I use an > ESQL 7.1, development system >with an > Online 5.1 development engine >to build up my application? For pure ESQL/C applications, yes, you probably could, but you'd need a funny entry in your sqlhosts file to get it to work. Something along the lines of: special seipcpip localhost sqlturbo You'd need to set INFORMIXSERVER to special, you'd need the correct tbconfig file kicking around in the 7.1 INFORMIXDIR, you'd need to set TBCONFIG, etc. It is all very ghastly, and probably not supported. Alternatively, you might be able to use a net connection to the 5.x OnLine system. Whatever you have to do, it is not straight-forward. You cannot mix the 7.1 ESQL/C with any I4GL code. You need 6.0x I4GL anyway, though you probably could use all 4.1x if you really wanted to and didn't mind the overhead of the relay module on the released product. (Your customer will rightly object though -- the performance via the relay module is so bad that Informix released the 6.0x I4GL to get around the performance issue!) >If so, can I use the binary generated for installing and using it >at our customer, who has an > ESQL 7.1 runtime system >and an > Online 7.1 runtime engine? Depends on which version of I4GL you're using, but probably not. If you are using I4GL 6.0x, then Yes. If you are using I4GL 4.1x, and the answer should be No, because the customers machine will perform badly because you are making it use code that inherently slows it up and makes it do more work than it should. >The problem is that we are develloping software for a customer, but we >still have the older Online engine (5.1). Because we don't want to invest >any mony for a new Online engine (7.1), just for the ESQL (7.1), we hope >that this is possible. You are creating unnecessary hardship for yourself. >The same question holds on for the valid combinations of > 4GL (4.1 and 6.x) >and > Online engine (5.1 and 7.1) > >Thanks for any comments, >Chris > >P.S: I think that this is also an important and interesting information, >so it also should be included in the FAQ?! There are two inter-woven sets of compatability issues here. (1) Which versions of I4GL can work with which versions of ESQL/C. (2) Which front-end tools (I4GL, ESQL/C) can work with which engines. There are three main groups of versions to worry about: 4.1x => 4.10, 4.11, 4.12, 4.13, 4.14, 4.15, ... 5.0x => 5.00, 5.01, 5.02, 5.03, 5.04, 5.05, 5.06, ... 6.0x+ => 6.00, 6.01, 6.02, 6.03, 7.10, 7.11, 7.12, 7.20, etc Note that there is no 5.0x or 7.1x version of I4GL. Generally speaking, connectivity within a group is relatively straight-forward and there are few problems. However, at the fine detail level, you would want to distinguish between the 6.0x family, the 7.1x family and the 7.2x family. I4GL & ESQL/C ============= 4.1x I4GL works with 4.1y ESQL/C. For x <= 2, y == x; for x > 2, y == 2. There are no versions of ESQL/C later than 4.12. Never try mixing 4.1x I4GL with any later version of ESQL/C -- if it links at all (improbable), it will break because of internal incompatabilities in the call interfaces, etc. 6.0x I4GL works with 6.00 ESQL/C (or, using the notation for the 4.1x versions, 6.0x I4GL works with 6.0y ESQL/C where y == 0 for x >= 0). Trying to mix a later version of ESQL/C with 6.0x I4GL may or may not work -- some of the semi-internal routines change interface between 6.00 and 7.1x ESQL/C. Tools & Engines =============== Forward compatability is good. In general, applications written using the older ESQL/C and I4GL products can access newer Engines. Sometimes there is a performance hit in doing so -- most noticably, there is a big hit when a pre-6.00 application accesses a 6.00 or later Engine, because the request must go through a relay module. Tools Engines 4.1x 4.1x OK 4.1x 5.0x OK 4.1x 6.0x+ OK but performance hit 5.0x 5.0x OK 5.0x 6.0x+ OK but performance hit 6.0x+ 6.0x+ OK Going backwards is much more problematic and is generally unsupported. If your application software written using 6.0x+ Tools uses a feature which is only available in 6.0x+ Engines, it will not work when run against a 4.1x or 5.0x Engine, period. Even if the application code uses only 4.1x features, connecting backwards is not usually supported, and can be complex to set up. You have a fair chance of making a 5.0x application work against a 4.1x engine if you set SQLEXEC to the correct engine and ensure that any other connectivity environment issues are resolved correctly. Likewise, you will find that a 7.1x application stands a fair chance of talking to a 6.0x Engine. As I said earlier, I believe you can get a 6.0x+ application to talk to a 5.0x Engine, but you will find it easiest if you use a network connection (eg oltctcp) and it won't work with olipcshm. You may be able to use seipcpip if you specify sqlturbo as the service, and get everything else fudged correctly. I think this is self-consistent and correct; please supply amendments where necessary. If the amendments are about interworking within the 6.0x+ family, then you are probably correct, and I've simply glossed over the details. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>