Re: HELP!!! Global Language Support

On Fri, 04 Sep 1998 12:09:38 -0400, Chad Laity <chad_laity@arrowintl.com> wrote: >I have a 3rd party application (Documentum) that uses an Informix >database to store data. When I insert extended ASCII characters into >the database by telneting to the server and use Informix DBACCESS the >data is inserted just fine. > >For example (note the special characters): > >insert into coord_table (facility, coord_name,coord_address) values >('3333','Ord''ez','3333');> >When I telnet to the server and use the 3rd party app, the extended >ASCII characters are removed. I have muddled through the GLS guide but >I need some insight. The 3rd Party software insists that it is not >their product. They tell me that Informix must use a particular >setting/env variable internally for the products (like DBACCESS) that is >NOT used when connecting via the connection library provided by >Informix. What connection method do they use and what version and what version of what engine do you have? All new connection methods use the DB_LOCALE and CLIENT_LOCALE environment variables. May be they have linked and delivered the application with some old version of something that doesn't understand these variables? May be it understands NLS so you have to set some NLS related variables. I don't know if that is ever needed or possible but you might want to check if there are version problems that can't easily be resolved. As I have been told there was a bug in early versions that supported GLS in that the default locale (when no _LOCALE variables are set at all) was supposed to be something that accepted 8 bit characters, but didn't anyway. This should have been fixed in some later version so that if your one and only purpose is to be able to insert 8 bit characters from the ISO 8859-1 character set you shouldn't need to be bothered with any of these things. If you however wanted a spesific sort order based on your character set or some of the other things supported by GLS (non ISO 8859-1 character set, date format ++) you of course need to set the variables. >I have tried various env setting such as >DB_LOCALE="en_US.819@dict",CLIENT_LOCALE="en_US.819@dict",and>SERVER_LOCALE="en_US.819@dict" for the 3rd party admin login. I wouldn't ever set SERVER_LOCALE to anything. That's for the engine itself to find and write data to it's different files. As far as I understand that part of it, a wrong setting here would lead to problems. I also don't know any reason why one would want to set it other than possibly if the DBA didn't understand english. >Any suggestions?? >Thanks, >Chad Laity >chad_laity@arrowintl.com Nils Myklebust NM Data AS Norway E-mail: Nils.Myklebust@nmdata.com FAQ at: http://www.iiug.org/techinfo/faq/faq_top.html (Now with ODBC info under "Third party products".)