Migrating 32-bit Informix ODBC applications to 64-bit

Informix® 64-bit ODBC driver binaries have been available for many years, but the true 64-bit Informix ODBC driver was not introduced until Informix Client SDK v4.10 in early 2013. This article discusses the differences between the Informix 64-bit binaries of the Informix ODBC driver and the newer, true 64-bit driver. Also learn how to migrate your current 32-bit or 64-bit Informix ODBC applications to take advantage of the true 64-bit driver.

Share:

Yunming Wang (yunming@us.ibm.com), Advanced Support Engineer, IBM

Yunming WangYunming Wang is an advanced support engineer on the Informix Advanced Problem Diagnostics (APD) team. Since 1998, he has focused on Informix, DB2 programming APIs, and database connectivity. His areas of specialization include ODBC, JDBC, OLEDB/.Net, ESQL/C, and TCP/IP. Before joining Informix/IBM, Yunming was a software developer. He received a master's degree in Computer System Engineering from the University of Arkansas in 1995.



01 May 2014

Also available in Chinese

Introduction

Almost every new computer, including a personal computer, is 64-bit capable. More and more systems are running a 64-bit operating system due to its obvious advantages over a 32-bit system. 64-bit systems can handle integer size and memory addresses of 64-bit width, meaning better performance and scalability in general. 64-bit systems can run both 32-bit and 64-bit applications provided that the 32-bit and 64 bit applications are linked to 32-bit libraries.

Download Informix database software to give it a test drive.

IBM Informix began shipping a 64-bit Open Database Connectivity (ODBC) library back in Client SDK (CSDK) version 2.20 for all supported UNIX® platforms such as AIX®, HP-UX, Solaris, and so on. For Linux® and Windows®, Informix did not ship a 64-bit ODBC library until Client SDK version 2.90 and 3.00, respectively. The version number of a 64-bit Informix ODBC driver contains the letter F, which indicates the driver is compiled in 64-bit mode regardless of the platform. For example, Informix Client SDK v3.70.FC7 means that the client is built in 64-bit mode on a platform that can be Windows, Linux, or UNIX. The Informix 64-bit ODBC driver before version 4.10 is actually 64-bit binary without all the changes included in the true 64-bit ODBC API, so it is not completely compatible with the 64-bit ODBC specification.

IBM introduced the first true 64-bit ODBC driver in IBM Informix Client SDK version 4.10. This new 64-bit ODBC driver includes all the changes required to support 64-bit ODBC and it is fully compatible with the 64-bit ODBC driver managers widely used on UNIX, Linux, and Windows.

This article discusses the differences between the 64-bit binaries and drivers. You learn how to migrate your older applications to take advantage of the true 64-bit driver. All the code and command examples in this article are for demonstration purposes only.


Differences between the 32-bit and 64-bit ODBC API

Before you start migrating your 32-bit ODBC application to 64-bit, it's important to understand the differences between the 32-bit and 64-bit ODBC API.

In general, the APIs differ in that 32-bit ODBC API can only handle 4-byte memory address pointers and integers. Simply recompiling the code of existing 32-bit ODBC in 64-bit mode is not usually enough because integers and longs can still be 4 bytes wide even if the memory address pointer becomes 64-bit. To ensure that 8-byte integer parameters passed in ODBC API are handled properly, 64-bit ODBC declares SQLLEN and SQLULEN data types as 8-byte integers across the 64-bit platforms.

Depending on the platform, SQLLEN and SQLULEN are declared differently. For 32-bit platforms, they are declared as 4-byte integers and unsigned integers, respectively. For 64-bit platforms they are declared as 8-byte integers and unsigned integers.

For example, on Windows, SQLLEN and SQLULEN are declared in the sqltypes.h header file, as in Listing 1.

Listing 1. Declaration of SQLLEN and SQLULEN in sqltypes.h on Windows
#ifdef _WIN64
typedef INT64           SQLLEN;
typedef UINT64          SQLULEN;
#else
#define SQLLEN          SQLINTEGER
#define SQLULEN         SQLUINTEGER
#endif

On Linux or UNIX, you will see that the SQLLEN and SQLULEN are declared similarly in the sqltypes.h header file from Progress DataDirect ODBC, as in Listing 2.

Listing 2. Declaration of SQLLEN and SQLULEN in sqltypes.h on Linux or UNIX
#if defined(ODBC64)
typedef INT64           SQLLEN;
typedef UINT64          SQLULEN;
#else
#define SQLLEN          SQLINTEGER
#define SQLULEN         SQLUINTEGER
#endif

Accordingly, some ODBC functions and descriptor fields that are set and gotten by pointers have also been changed to accommodate 64-bit values using SQLLEN or SQLULEN. For example, the SQLColAttribute() function is declared differently in a 64-bit Microsoft sqltypes.h header file, as in Listing 3.

Listing 3. Declaration of SQLColAttribute() in Microsoft ODBC
#ifdef _WIN64
SQLRETURN  SQL_API SQLColAttribute (
           SQLHSTMT StatementHandle,
           SQLUSMALLINT ColumnNumber, SQLUSMALLINT FieldIdentifier,
           __out_bcount_opt(BufferLength) SQLPOINTER CharacterAttribute,
           SQLSMALLINT BufferLength,
           __out_opt SQLSMALLINT *StringLength,
           __out_opt SQLLEN *NumericAttribute);
#else
SQLRETURN  SQL_API SQLColAttribute (
           SQLHSTMT StatementHandle,
           SQLUSMALLINT ColumnNumber,
           SQLUSMALLINT FieldIdentifier,
           __out_bcount_opt(BufferLength) SQLPOINTER CharacterAttribute,
           SQLSMALLINT BufferLength,
           __out_opt SQLSMALLINT *StringLength,
           __out_opt SQLPOINTER NumericAttribute);
#endif

The same function is declared similarly on UNIX and Linux in the Progress DataDirect ODBC sql.h header file, as in Listing 4.

Listing 4. Declaration of SQLColAttribute() in DataDirect ODBC sql.h header
#if defined(_WIN64) || defined(ODBC64)
SQLRETURN  SQL_API SQLColAttribute (
           SQLHSTMT StatementHandle,
           SQLUSMALLINT ColumnNumber,
           SQLUSMALLINT FieldIdentifier,
           SQLPOINTER CharacterAttribute,
           SQLSMALLINT BufferLength,
           SQLSMALLINT *StringLength,
           SQLLEN *NumericAttribute);
#else
SQLRETURN  SQL_API SQLColAttribute (
           SQLHSTMT StatementHandle,
           SQLUSMALLINT ColumnNumber,
           SQLUSMALLINT FieldIdentifier,
           SQLPOINTER CharacterAttribute,
           SQLSMALLINT BufferLength,
           SQLSMALLINT *StringLength,
           SQLPOINTER NumericAttribute);
#endif

The SQLLEN and SQLULEN data types in the Informix ODBC driver are declared similarly to ODBC driver managers. Because IBM ships the 32-bit and 64-bit Informix ODBC drivers separately, SQLLEN and SQLULEN are declared differently in the infxsql.h header file, depending on the version of Informix ODBC driver, without using a compiling directive.

In the 32-bit Informix ODBC driver as well as the 64-bit Informix ODBC driver binaries version 3.70 and before, SQLLEN and SQLULEN are defined as 4-byte integers. Listing 5 shows an example, where SQLINTEGER and SQLUINTEGER, which are both 4-byte integers, are defined as sqlint32 and unsqluint32 respectively.

Listing 5. Declaration of SQLLEN and SQLULEN in 32-bit Informix ODBC infxsql.h header
#define SQLLEN          SQLINTEGER
#define SQLULEN         SQLUINTEGER

In the 64-bit Informix ODBC driver, SQLLEN and SQLULEN are defined as 8-byte integers, as in Listing 6.

Listing 6. Declaration of SQLLEN and SQLULEN in 64-bit Informix ODBC infxsql.h header
typedef unsigned long long  SQLULEN;
typedef long long           SQLLEN;

Other than the difference of SQLLEN and SQLULEN declaration between a 32-bit and 64-bit Informix ODBC driver, all Informix ODBC API functions are declared the same beginning with version 2.90. There is no need to change your ODBC application if you declare your host variables the same way as the signatures of Informix ODBC functions. However, the Informix ODBC functions in Listing 7 are modified to support the new 8-byte SQLLEN and SQLULEN data type in Informix ODBC 4.10.FC1.

Listing 7. Informix ODBC functions affected by 8-byte SQLLEN and SQLULEN in v4.10.C1
SQLBindCol
SQLBindParam
SQLFetchScroll
SQLGetData
SQLGetDescRec
SQLPutData
SQLRowCount
SQLSetDescRec
SQLSetParam
SQLColAttributeW
SQLColAttributesW
SQLGetDescRecW

As previously described, SQLLEN and SQLULEN are still 4 bytes long in the Informix 64-bit ODBC driver binary in version 3.70 and before. Your 64-bit ODBC applications that are currently compiled and linked with Informix 64-bit ODBC libraries version 3.70 and before cannot fully benefit from your 64-bit system, even if you run your Informix ODBC applications with the newer, true 64-bit ODBC driver. In addition, calling Informix ODBC APIs that take parameters of SQLULEN or SQLLEN from a true 64-bit ODBC driver manager can give you unpredictable problems, such as data truncation, memory corruption, and so on. This is discussed in more detail in the next section.


Migrating 32-bit Informix applications to 64-bit mode

As mentioned, the INFORMIXDIR/incl/cli/infxsql.h header file has been modified for the true 64-bit Informix ODBC driver. Thus, you must recompile your current 32-bit or 64-bit Informix ODBC applications with the newer, true 64-bit Informix Client SDK to migrate your applications to pick up the changes in the full 64-bit ODBC driver. Depending on whether or not your Informix ODBC application runs with ODBC driver manager, you need to recompile your Informix ODBC application with proper compiling directives defined by the ODBC driver manager.

Migrating stand-alone Informix ODBC applications to 64-bit mode

If your Informix ODBC applications are stand-alone and do not run with ODBC driver manager, you can simply recompile them without using any 64-bit ODBC specific compiling directives—provided that all ODBC API functions are called with all parameters declared the same way as the signature of each function declared in the infxsql.h Informix ODBC header file.

The following is an example on Linux.

gcc -o
fxODBCTest -I$INFORMIXDIR/incl/cli  -L$INFORMIXDIR/lib/cli -lthcli -lifdmr
    -L$INFORMIXDIR/lib/esql -lgls -lifglx ifxODBCTest.c

If your ODBC applications still call ODBC API functions in the 32-bit fashion, you must modify your code accordingly to comply with the 64-bit ODBC driver. It's quite common and nonstandard with legacy ODBC applications to use a different data type to declare variables from those specified in ODBC API function prototypes.

The code in Listing 8 shows an example of calling the SQLExtendedFetch() function, with argument pcrow declared as UDWORD, that is different from the SQLExtendedFetch() function prototype.

Listing 8. Calling SQLExtendedFetch() with 32-bit signature
   UWORD Row_Stat[ROWSET_SZ];
   UDWORD pcrow;
   ......
    while ((rc = SQLExtendedFetch(hstmt,
		SQL_FETCH_NEXT,
		0,
		&pcrow,
		Row_Stat)) == SQL_SUCCESS)
      {
        /* do something here */
      }

There is no problem with the code in Listing 8 when it's compiled with 64-bit Informix ODBC driver binaries version v3.70 or before because SQLLEN is 4 bytes long. Passing the memory address of the pcrow that is declared as UDWORD to SQLExtendedFetch is OK. However, after you upgrade your 64-bit Informix ODBC driver to the true 64-bit one in v4.10, recompiling the application is not enough because SQLLEN is now 8 bytes long in the new driver but UDWORD is still 4 bytes. The 8-byte data stored at the memory address of the pcrow variable will be truncated to 4-byte in size at runtime and cause corruption to the data held by the pcrow variable. In this case, you must also modify your application code to use the same data type.

For example, Listing 9 shows a small program that retrieves data from the customer table in the Informix stores_demo database using column-wise binding.

Listing 9. Calling SQLExtendedFetch() with 32-bit signature
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#ifdef IFXODBC
  #include "infxcli.h"
  #include "infxsql.h"
#else
  #include "sql.h"
  #include "sqlext.h"
#endif


#define ROWSET_SZ 2

int main()
{
   SQLHENV henv = SQL_NULL_HENV;
   SQLHDBC hdbc = SQL_NULL_HDBC;
   SQLHSTMT hstmt = SQL_NULL_HSTMT;
   RETCODE retcode;
   SQLCHAR szFname[ROWSET_SZ][32];
   SQLLEN cbFname[ROWSET_SZ], cbCust_num[ROWSET_SZ];
   UWORD Row_Stat[ROWSET_SZ];
   UDWORD pcrow;
   SQLINTEGER Cust_num[ROWSET_SZ];

   long int i = 0, total = 0;

      // Allocate the ODBC environment and save handle.
      retcode = SQLAllocHandle (SQL_HANDLE_ENV, NULL, &henv);
      if ( (retcode != SQL_SUCCESS_WITH_INFO) && (retcode !=
SQL_SUCCESS))
      {
         printf("SQLAllocHandle(Env) Failed\n\n");
         return(1);
      }

      // Notify ODBC that this is an ODBC 3.0 app.
      retcode = SQLSetEnvAttr(henv,
		SQL_ATTR_ODBC_VERSION,
		(SQLPOINTER) SQL_OV_ODBC3,
		SQL_IS_INTEGER);
      if ( (retcode != SQL_SUCCESS_WITH_INFO) && (retcode !=
SQL_SUCCESS))
      {
         printf("SQLSetEnvAttr(ODBC version) Failed\n\n");
         return(1);
      }

      // Allocate ODBC connection handle and connect.
      retcode = SQLAllocHandle(SQL_HANDLE_DBC,
		henv, &hdbc);
      if ( (retcode != SQL_SUCCESS_WITH_INFO) && (retcode !=
SQL_SUCCESS))
      {
         printf("SQLAllocHandle(hdbc) Failed\n\n");
         return(1);
      }

      // Connect to Informix server
      if (hdbc != 0)
      {
        retcode = SQLConnect(hdbc,
		(SQLCHAR*) "IfxDSN", SQL_NTS,
		(SQLCHAR*) "informix", SQL_NTS,
		(SQLCHAR*) "mypassword", SQL_NTS);
      }

      if ( (retcode != SQL_SUCCESS) && (retcode !=
SQL_SUCCESS_WITH_INFO) )
      {
         printf("SQLConnect() Failed\n\n");
         return (1);
      }

      // Allocate ODBC statement handle for an SQL statement.
      retcode = SQLAllocHandle(SQL_HANDLE_STMT,
		hdbc, &hstmt);
      if ( (retcode != SQL_SUCCESS) && (retcode !=
SQL_SUCCESS_WITH_INFO) )
      {
         printf("SQLAllocHandle(hstmt) Failed\n\n");
         return(1);
      }

      // Execute an SQL statement.
      retcode = SQLExecDirect(hstmt,
		(UCHAR*)"SELECT CUSTOMER_NUM, FNAME FROM CUSTOMER", SQL_NTS);

      // Set the row size to ROWSET_SZ
      retcode = SQLSetStmtAttr(hstmt, SQL_ROWSET_SIZE, (void*) ROWSET_SZ,
0);

      // Retrieve the rows.
      retcode = SQLBindCol(hstmt, 1, SQL_C_SLONG, (SQLPOINTER) Cust_num, 4,
cbCust_num);
      retcode = SQLBindCol(hstmt, 2, SQL_C_CHAR, (SQLPOINTER) szFname, 32,
cbFname);

      while ((retcode = SQLExtendedFetch(hstmt,
		SQL_FETCH_NEXT,
		0,
		&pcrow,
		Row_Stat)) == SQL_SUCCESS)
      {
         for (i = 0; i < pcrow; i++)
         {
           total++;
         }
         if (pcrow < ROWSET_SZ)
            break;
      }

      printf("Total number of rows fetched: %ld\n", total);

   // Free the statement handle
   SQLFreeHandle(SQL_HANDLE_STMT, hstmt);

   // Disconnect and free the handles
   retcode = SQLDisconnect(hdbc);
   if ( (retcode != SQL_SUCCESS) && (retcode !=
SQL_SUCCESS_WITH_INFO) )
   {
      printf("SQLDisconnect(hdbc) Failed\n\n");
      return(1);
   }
   SQLFreeHandle(SQL_HANDLE_DBC, hdbc);
   SQLFreeHandle(SQL_HANDLE_ENV, henv);

   return (0);
}

The pcrow variable is still declared as UDWORD in this example. When compiling it with Informix CSDK 3.70.FC7, you would not see any warning or error messages. Now let's try to compile it with CSDK v4.10.FC1, which is installed under /work/ywang/csdk410fc1 on an AIX 7.1 machine, as in Listing 10.

Listing 10. Compile with CSDK v4.10.FC1
export INFORMIXDIR=/work/ywang/csdk410fc1
export INFORMIXSQLHOSTS=/work/ywang/sqlhosts
export PATH=${INFORMIXDIR}/bin:${PATH}
export
LIBPATH=${INFORMIXDIR}/lib:${INFORMIXDIR}/lib/esql:${INFORMIXDIR}/lib/cli:
${LIBPATH}
$ gcc -o
listing9 -DIFXODBC -I$INFORMIXDIR/incl/cli -L$INFORMIXDIR/lib/cli -lthcli
-lifdmr -L$INFORMIXDIR/lib/esql -lgls -lifglx listing9.c

The compiling process should finish OK with a warning message because the data type pcrow mismatches with that declared in the function signature, as in Listing 11.

Listing 11. Message
cc -qchars=signed -q64 -qlanglvl=extc99 -qalign=natural
 -qcheck=nullptr -qmaxmem=-1
-qspill=2000 -o
listing9 -DIFXODBC -I$INFORMIXDIR/incl/cli -L$INFORMIXDIR/lib/cli -lifcli
-lifdmr -L$INFORMIXDIR/lib/esql -lgls -lifglx -ltli -lc_r -lmsaa -lm_r -ldl 
-lbsd
listing9.c

"listing9.c", line 78.68: 1506-280 (W) Function argument assignment between
types
"unsigned long long*" and "unsigned int*" is not allowed.

If you ignore the warning message and run the program, you would see no row returns:

    $ listing9
    Total number of rows fetched: 0

Let's add the following code in the while loop to display the value of pcrow:

            printf("pcrow = %ld\n", pcrow);

Recompile listing9.c and rerun it, as in Listing 12.

Listing 12. Rerun
    $ listing9
    pcrow = 0
    Total number of rows fetched: 0

It turns out that pcrow is returned as 0 by SQLExtendedFetch(). The value held in the pcrow variable gets truncated because it is declared as a 4-byte UDWORD in the program, whereas it is declared as an 8-byte SQLULEN in the signature of the SQLExtendedFetch() function, as in Listing 13.

Listing 13. Truncation
SQLRETURN SQL_API SQLExtendedFetch(
	SQLHSTMT		hstmt,
	SQLUSMALLINT	fFetchType,
 	SQLLEN		irow,
	SQLULEN		*pcrow,
	SQLUSMALLINT	*rgfRowStatus);

When the SQLExtendedFetch() Informix ODBC API function returns, the value contained at the &pcrow is stored as 0x00000000 00000002 on a big endian system (AIX in this case). Because pcrow is declared as a 4-byte integer in the program, the second 4 bytes of memory are truncated and hence the value of 0x0000000.

This example shows how important it is to declare variables with the data types that are used in the ODBC function signature. Mismatching data types between the local variables and ODBC API functions can cause unnecessary data type conversion and possible data truncation. You need to review your application code to make sure the correct data types are used for local variables and examine all the warning messages during the compiling time.

Migrating Informix ODBC applications compiled and run with an ODBC Driver Manager to 64-bit mode

For the Informix ODBC applications that are compiled and run with an ODBC Driver Manager such as Progress DataDirect ODBC or unixODBC, Informix ODBC driver is not compiled and linked directly to the application. Informix ODBC driver shared libraries are actually loaded by the driver manager at runtime. In this case, the ODBC application must still be recompiled with your ODBC driver manager, so the size of SQLLEN and SQLULEN are determined by the ODBC driver manager you are using. It is possible that the size of SQLLEN and SQLULEN declared by the ODBC driver mismatches that declared by Informix ODBC driver. To ensure that the 64-bit Informix ODBC driver behaves correctly, the size of SQLLEN and SQLULEN declared in the ODBC driver manager must match with the Informix ODBC driver. Assuming all the variables are declared correctly in the application, it is important that you recompile it with the proper 64-bit ODBC specific compiling directive of the driver manager.

Let's look at the sqltypes.h header file where the directive for 64-bit ODBC is defined in unixODBC, DataDirect, and Microsoft ODBC driver manager.

unixODBC:

	SQLRETURN SQL_API SQLExtendedFetch(
	#ifdef BUILD_LEGACY_64_BIT_MODE
	typedef int             SQLINTEGER;
	typedef unsigned int    SQLUINTEGER;
	#define SQLLEN          SQLINTEGER
	#define SQLULEN         SQLUINTEGER
	#define SQLSETPOSIROW   SQLUSMALLINT

Progress DataDirect ODBC:

	#if defined(ODBC64)
	#ifdef _WIN64
	#ifndef _BASETSD_H_
	typedef __int64 INT64;
	typedef unsigned __int64 UINT64;
	#endif
	#else

	#ifndef _DLFCN_INCLUDED
	typedef unsigned long   UINT64;
	#endif

	typedef signed long     INT64;
	#endif
	typedef INT64           SQLLEN;
	typedef UINT64          SQLULEN;
	typedef UINT64          SQLSETPOSIROW;

Microsoft's ODBC:

	#ifdef _WIN64
	typedef INT64           SQLLEN;
	typedef UINT64          SQLULEN;
	typedef UINT64          SQLSETPOSIROW;

On 64-bit Windows, the _WIN64 macro is automatically defined if you select x64 as your new solution platform in your Visual Studio project to recompile your ODBC application.

On UNIX and Linux platforms, Informix ODBC applications are usually compiled with a makefile that defines all the compiling options, including the directives for all the shared libraries. If your Informix ODBC applications are compiled with an ODBC driver manager, you need to modify your makefile to include the proper compiling directive for the ODBC driver manager.

As an example, let's recompile list9.c with the Progress DataDirect ODBC driver manager on a Linux machine, as in Listing 14. The compiling directive for 64-bit Progress Data Direct ODBC driver manager is ODBC64. The pcrow variable is still declared as SQLULEN.

Listing 14. Recompile with Progress DataDirect ODBC driver manager
export ODBCHOME=/home/ywang/ddodbc64
gcc -g -DODBC64 -o listing9 -L$ODBCHOME/lib -lodbc -I$ODBCHOME/include
listing9.c

After running the program, you will see all rows returned, as follows:

  $ listing9
  Total number of rows fetched: 29

Regardless of the ODBC driver manager, you can check the size of the pcrow variable in a debugger.

For example, on AIX, you can check it in dbx by putting a breakpoint in SQLExtendedFetch, as in Listing 15.

Listing 15. Checking on AIX
$ dbx listing9
Type 'help' for help.
reading symbolic information ...

(dbx) stop in SQLExtendedFetch
[1] stop in SQLExtendedFetch

(dbx) run
[1] stopped in glink64.SQLExtendedFetch at 0x100000be8 ($t1)
0x100000be8 (SQLExtendedFetch)    e98200c8          ld   r12,0xc8(r2)

(dbx) p sizeof(&pcrow)
8

On Linux, you can check it in gdb in the same way, as in Listing 16.

Listing 16. Checking on Linux
......

(gdb) p pcrow
$1 = (SQLULEN *) 0x7fff0425c80c

(gdb) p sizeof(SQLULEN)
$2 = 8

Troubleshooting

When migrating your 32-bit Informix ODBC application to 64-bit, problems can occur. Usually, problems are caused by mislinking the application to the wrong shared libraries or mismatching data types between the application variables and ODBC function parameters.

If you're troubleshooting problems with 64-bit ODBC applications, the following guidelines might be helpful:

  • Make sure that the ODBC program is compiled properly with the required compiling directive if ODBC driver manager is used.
  • Minimize the compiling warning messages if possible, especially those related to data types.
  • Run the ldd > program name < command to make sure the application is linked to the correct shared libraries.
  • Verify that your ODBC.INI file is configured properly.

If you're sure that everything is set right and the problem still occurs, consider collecting the following diagnostic data for further troubleshooting:

  • ODBC trace
  • Informix SQLIDEBUG output

For information about how to collect ODBC trace and Informix SQLIDEBUG output, see Collecting data for an ODBC Problem.

As always, you can contact IBM technical support for assistance whenever needed.


Conclusion

The Informix ODBC driver shipped before 64-bit Informix Client SDK v4.10.FC1 is 64-bit binary and does not take full advantage of the newer, true 64-bit ODBC driver. Migrating 32-bit Informix ODBC applications, or 64-bit applications compiled with 64-bit Informix CSDK before version 4.10.FC1, must be recompiled with the new Informix 64-bit ODBC driver version 4.10.FC1 or later. If you use a third-party ODBC driver manager, you must compile the ODBC applications with proper compiling directives for 64-bit ODBC driver manager.

Resources

Learn

Get products and technologies

  • Evaluate IBM products in the way that suits you best: Download a product trial, try a product online, or use a product in a cloud environment.

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Information management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Information Management
ArticleID=970065
ArticleTitle=Migrating 32-bit Informix ODBC applications to 64-bit
publish-date=05012014