ESQL/C porting
Posted in 1999
Topics: Connectivity: ESQL/C, 4GL & Embedded SQL, Migration, Import/Export & Data Conversion
We have an application developed in ESQL/C 5.1 running on old informix server 5.x. We are planning to migrate it to latest informix database server. Application extensively use dynamic SQL (sqlda). Can anyone provide a list or pointers where I can find what all has changed since version 5.1 of ESQL/C till the current version. Also ccan someone share his/her practical experience doing this type of migration. Amy help or pointers will be greatly appreaciated. Please send an email at achinb@aol.com Thanks, Amit
AchinB wrote: > > We have an application developed in ESQL/C 5.1 running on old informix server > 5.x. We are planning to migrate it to latest informix database server. > Application extensively use dynamic SQL (sqlda). > > Can anyone provide a list or pointers where I can find what all has changed > since version 5.1 of ESQL/C till the current version. > > Also ccan someone share his/her practical experience doing this type of > migration. There are no backward incompatibility issues going from ESQL 5.xx to ESQL 7.xx or to the SDK 2.xx (ESQL 9.xx) compilers. The newer compilers have several new and interesting features but you do not have to take advantage of any of them unless you want to. Notably that news ESQL's support multiple connections (if you have code that selects from tables on more than one server using a separate connection to each server rather than accessing all but one server as remote will speed your applications and reduce the load on the default server which will no longer be acting as a pass-through for all that remote data) and threads support (you can have multiple threads either each with its own connection to the server or sharing a limited number of connections cooperatively {only on thread can access a connection at a time} which can help take advantage of large SMP servers). Support in the source for structures has been improved so some of your code can be made simpler and easier to maintain. I normally suggest a four step approach: 1) Install the new server and development software and set up the environment to point to the 5.xx engine (ie add the network and pipe connections from the 5.xx sqlhosts file to the empty 7.xx sqlhosts file, you will not be able to use a shared memory connection this way). 2) Recompile and relink applications with the new compilers and test run in the 7.xx runtime environment but pointed at the 5.xx engine. (ESQL 7/9.xx compiled applications actually run faster against a 5.xx server than ESQL 5.xx compiled versions do so you gain something right away and only have to test the recompiled code at this point.) 3) Once a majority of your code has been ported and you are confident that it works and that you understand all the little problems the remainder might run into it is time to upgrade the engine version. Shutdown, update the sqlhosts and new ONCONFIG file, start up the new version and wait for the indexes et al to be converted. Note that 7.xx indexes and some other disk structures take up a bit more space than their 5.xx counterparts so you should probably add space to dbspaces that are getting tight. 4) Now that you have a running tested system you are ready to start taking advantage of all that your new server and compiler have to offer. Look into fragmenting tables for performance (watch out for code that assumes that all tables have a rowid pseudo-column - fragmented tables do not {you have to add a hidden real column w/index with the WITH ROWID clause at CREATE or ALTER time}). See where you can take advantage of multiple connections or threads. Look into other new features: If you have a 7.3x engine and SDK 2.xx compiler you can now DESCRIBE update statements. In 5.xx you had to DESCRIBE a SELECT statement with the same columns and convert the sqlda structures. Look into changing DESCRIBE from proprietary sqlda structure use to using the newer ANSI DESCRIPTOR AREA which is more portable. Similarly look into whether you want to change your error handling from checking the sqlca structure to using the new portable ANSI error handling. Art S. Kagel