Review client applications

After you migrate a database server on the same operating system or move the database server to another compatible computer, review the client applications to take necessary actions related to migration. If necessary, recompile or modify client applications.

General guidelines

Post migration, review the client applications and sqlhosts file or registry-key connections. Recompile or modify client applications if necessary. Verify that the client-application version you use is compatible with your database server version. If necessary, update the sqlhosts file or registry key for the client applications with the new database server information.

Migrating ODBC applications

If you have a 64-bit ODBC application that was compiled and linked with a version of HCL Informix® Client Software Development Kit (Client SDK) that is prior to version 4.10, you must recompile the application after migrating. The SQLLEN and SQLULEN data types were changed to match the Microsoft 64-bit ODBC specification. Be sure to analyze any functions that take either of these data types to ensure that the correct type passes to the function. This step is crucial if the type is a pointer. Also note that in the ODBC specification, some parameters that were previously SQLINTEGER and SQLUINTEGER were changed to SQLLEN or SQLULEN.

Large Row Identifiers and Their Implications for Old and New Clients

Immediately after the successful completion of an in-place migration, an Informix 15.0.0 instance is in compatibility mode, meaning that most new features are disabled. Enabling all Version 15.0.0 features requires switching your instance from compatibility mode to native mode.

If you perform a complete disk initialization using Informix Version 15.0.0, the instance will begin and always remain in native mode.

Tables created by Informix Version 15.0.0 in native mode use 8-byte row identifiers by default. The new rowid size and format allow these new tables to grow much larger than they did prior to Version 15.0.0. Tables that make use of large rowids are called LARGE tables.

Because rowids are embedded in the sqlca structure, which is passed back and forth between clients and the server, applications must be prepared for a new version of sqlca if they want to take advantage of the larger rowids.

New applications compiled and linked using ClientSDK version 15.0.0 are already compatible with large rowids. Applications that communicate with the server using the Version 15.0.0 ODBC or JDBC drivers will also recognize large rowids along with the new sqlca structure.

If you want a legacy application to make use of large tables, before connecting it to a Version 15.0.0 instance in native mode you should recompile and relink the application with the version 15 header files and libraries. Note that because of the changes to internal structures the Version 15.0.0 libraries have new names.

Version 15.0.0 also supports tables that use legacy 4-byte rowids. A table migrated from an earlier version of the server, for example, will always use 4-byte rowids. These are called SMALL tables. All tables created while the instance is in compatibility mode will be in small table format. Small tables may also be explicitly created while in native mode.

Applications compiled and linked with prior versions of the CSDK will continue to work with the Version 15.0.0 server, but only with small tables. If they attempt to create or read a large table they will receive a new error number:

-21569  This client cannot create or open tables that use large rowids.

Even when in native mode, all system catalogs, and all tables in system databases such as sysmaster, sysadmin, sysutils, sysuser, and sysha are in “small table” format so that both new and old clients may access them.

ROWID Columns

When a new application selects the ‘rowid’ hidden column from a non-fragmented table, the type of that column is BIGINT, whether the table is large or small. A legacy application that cannot access large tables will continue to see this ‘rowid’ column as an INT type.

Note that a large internal rowid, when displayed in decimal format, will always be a very large negative number, e.g. -9223372036854710271.

When an application selects the ‘rowid’ hidden column from a large, fragmented table created using the WITH ROWIDS clause, the type of that column is BIGSERIAL. When a small fragmented table is created using the WITH ROWIDS clause, the type of the hidden ‘rowid’ column is SERIAL.

For more information about interactions between client applications and different database servers, refer to a client manual.