Quite honestly I would need to know the particulars of what you are doing.
If it is merely a connection then the variable you mentioned will most certainly do the trick.
For instance if all your original data was in a database whose DB_LOCALE was en_us.819, and the instance was upgraded, then merely setting the variable would eliminate any -23197 errors (locale mismatch)
If you had to unload your data before upgrading, you now run into the problem of generating corruption during the load and unload.
You would not get -23197 errors, but you might get something altogether different.
Another question, where did you set the environment variable? It has to be set on the Server side, and the instance must be bounced.
Finally, I hope the individual who let you know about this variable also warned you that setting it introduces the possibility of locale related corruption.
----- Original Message ----
From: Danilo Fiorenzano <tomade (AT) gmail (DOT) com>
To: informix-list (AT) iiug (DOT) org
Sent: Wednesday, November 7, 2007 6:28:26 PM
Subject: IFMX_UNDOC_B168163 for Cheetah?
Greetings all,
We are trying to get past the infamous "locale mismatch" problem after
upgrading the server side to IDS11.FC1, with a large periphery of
users with old ODBC DSN setups configured with the (wrong) default of
en_us.CP1252. We tried to use IFMX_UNDOC_B168163=1 as a temporary
workaround while trying to convert either side, but this does not seem
to be working. Did anyone successfully use that, or perhaps knows of
some other way to relax the locale check?
Thanks!!
--
Dan.
_______________________________________________
Informix-list mailing list
Informix-list (AT) iiug (DOT) org
http://www.iiug.org/mailman/listinfo/informix-list