One of the most commonly asked question:

"What do I have to do to make my Informix® 4GL or Informix® ESQL/C application work with different databases?"

Another particular area of expertise within 4GL & EsqlC development, which may be of interest to you, is the migration of a 4gl application database to make it database vendor independent, as well as the 4gl application modernisation which includes graphical clients, WebServices and Java Web Client Deployment.

Information on modernizing your application to support different databases with the same source code stream. 

Our experience in this migration process dates back to 1996, when it was first possible to migrate an Informix application and table data into Oracle in an almost fully automated process. Over the last few years, we have improved this process even further to support all common database systems and we can now proudly confirm ourselves as the market leader for Informix 4gl application migration technology. Our expertise assures you that there will be no need for your developers to be retrained, no need to keep multiple sets of database schemas for the different databases or to re-write any of your applications. 

"Querix makes migration across different database engines as easy as child's play. Its speed and reliability are really amazing. Querix is the best option for making our systems attractive and it has increased the life-cycle of our programs."

Daniel Rubino, Information Systems Manager, Drogueria Uruguay S.A.

A typical database migration process consists of four stages:

• Initial analysis of your current applications and RDBS environment
• Migration of the Informix table into the target database using standard Querix 4GL (create table)
• Migration of the Informix application to support other databases. This is discussed in more detail below, in the technical information on the database migration.
• Testing your newly database vendor independent applications (a full test cycle). 

Some technical information on the database migration: 

• The first task in any migration is to port the database schema. During this process, you may have to deal with any potential conflicts between object names and keywords, as the set of reserved SQL keywords differs from engine to engine.
• Once this step is completed, the next step is to check in advance for known problems and to deal with these as appropriate:
• There may be potential problems that may arise due to the manner in which the RDBMS handles transactions, since not all engines behave like Informix.
• It will be necessary to deal with non-ANSI SQL constructs that will not be supported in the target RDBMS (the most common being the MATCHES operator in SQL). In most cases, it will be a case of coding around the problem.
• It may be necessary to check for differences in the locking models, depending on how sensitive your application is to locking granularity.
• It may be necessary to check for differences in the isolation level behaviour, depending on how sensitive your application is to this.
• There will be other less general problems for specific RDBMS that will need to be dealt with on a case-by-case basis. Most of these are uncommon and are discussed in the appropriate migration guides we have prepared.

With these factors considered, it will simply be a case of compiling the 4GL code, and start testing. There are also specific database vendor migration documents available to download which will provide you with more detailed information.