Trouble with locales

If you've recently installed Informix Dynamic Server (IDS) 10.00.UC4 and have ODBC or other client applications, you might notice an error message like this when connecting to IDS:

[Informix][Informix ODBC Driver] Database locale information mismatch

The problem is related to a an IDS bug fix in 10.00.xC4. The defect is:

171156 ABLE TO CONNECT TO DATABASE CREATED WITH UTF8 LOCALE WITH CLIENT WHEN DB_LOCALE SET TO EN_US.8859-1

Prior to this bug fix IDS would not complain if the DB_LOCALE environment variable was set to en_US.CP1252 on the client and set to EN_US.8859-1 or EN_US.819 on the database server. This is a mis-match which is now correctly flagged as an error.

The problem is the default DB_LOCALE value on Windows in the United States used to be set to en_US.CP1252, so if you didn't specify otherwise there would be a locale mismatch between the client and server by default. The correct fix to this problem is to set the default DB_LOCALE value on the client to the same as the default value on the server. You can specify this in the ODBC connection string or when creating the DSN.

With IBM Informix Client Software Development Kit (CSDK) version 2.90.TC6 and higher the default United States DB_LOCALE is now set correctly and matches the server value. The related defects are:

175110 ICE : THE DEFAULT DB_LOCALE IN CREATING DSN'S ON WINDOWS SHOULD BE EN_US.819

and

175746 ICE : WHEN SETTING UP DSN, SHOULD GET THE DB_LOCALE FROM SERVER AND SET IT AS DEFAULT DB_LOCALE ON ENVIRONMENT TAB

The latter fix makes it easier to set up a DSN without worrying about locales.

If you really need this working and cannot wait for a CSDK fix, and cannot change your application to specify a DB_LOCALE that matches the server in the connection string, you can set the IDS server environment variable IFMX_UNDOC_B168163 to 1 (ignore the fact that "168163" does not match any of the above defect numbers). The server will then revert to the old behavior of accepting the mismatched locales - however it is much better not to do this - mismatched locales, even when similar, can potentially lead to data corruption.