Re: IFMX_UNDOC_B168163 for Cheetah?

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@gmail.com> To: informix-list@iiug.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@iiug.org http://www.iiug.org/mailman/listinfo/informix-list