Hello ,
we have an Informix Database that has Polish laguage data.
The database locale is CP1252.
The problem is that when we use the Informix .NET Client SDK Version
2.90.4.0 to retrieve this data
we get an Unspecified Error -21000 exception.
Moreover the characters of the polish language are not displayed
correctly.

I try to set db_locale=en_US.1252 and client_locale=en_US.8859-2 or
client_locale=en_US.1250
but i get
unable to load locale categories
or
database locale information mismatch
exceptions

Please help because i have tried nearly everything with no result !

Thanks

alexandrostrf (AT) gmail (DOT) com wrote:
Very "interestingt" subject... I'd say this is one of the hottest topic in tech
support.

I imagine you've been using the defaults (DB_LOCALE = CLIENT_LOCALE =
en_US.CP1252) with previous CSDK versions.
If it's so, you've been inserting Windows characters withou translation into
the database.
Starting with recent versions (2.90.TC4?), CSDK don't use CP1252 for DB Locale.
It uses the DB effective locale. This can cause the following problems:
- There are characters in CP1252 which don't have representation in other locales
- Some customers may have inserted CP1252 characters in databases with codesets
that don't have representation for them (because no conversion was being done)

As a workaround you should use the settings you were using before, but you have
to clean up your data by identifying which characters are invalid.

The important issue is the fact that CP1252 contains characters not supported
in other codesets. Examples are (you'll need MS Word for example to see them):
- Opening and closing double quotes
- A wider minus sign (Ifen sign?)

Please check your db locale with:

database sysmaster;
select * from sysdbslocale

If it's really CP1252 then you probably changed the CLIENT_LOCALE in your
client environment. If it isn't CP1252 and you need to force it the engine will
complain (if you're using a recent 10.00 version and possible latest 9.40). In
this later case you can set an environment variable before starting the engine
to allow connections with wrong DB_LOCALE. Guy Bowerman has a blog article on
this subject... A quick Google lookup should point to it.

Regards.

--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...

Hello and thank you for your response.
The problem is that this data is not ours but from another vendor.
I do not know what their locale was when they inserted the data.
I made the query and the database locale is en_US.CP1252.

Thanks !

Hello,
i try to insert a windows-1250 string (Polish) to a local database
(not the one where the problem occurs).
I insert it ok and i can see it correctly ONLY if i set the db_locale
to en_US.utf8
When i try en_US.1250 as db_locale i get exceptions.
Also when i set en_US.1252 or en_US.819 i get results but they are in
the wrong format (unreadable).

The problem is that with the database server where the problem occurs
(linux server) i cannot
set db_locale=utf8 in the client but i get exceptions.

Thanks !

alexandrostrf (AT) gmail (DOT) com wrote:
You probably are having situation where the characters don't have a match
between the polish character set and windows character set.
If this happens a few things can happen:
.. You get a client side error (-21xxx -21005 if I recall correctly)
.. The character is converted to a specific value and "lost" (not desirable at
all - more on this later). This means the back-conversion is not possible
.. The character is converted to a single and different character, so the
back-conversion is possible
.. You get a server side error (possible -202 for example)

When you use utf8 as the DB_LOCALE it probably doesn't happen because utf8 is
virtually capable of representing all the world characters (there will be
exceptions, but it won't be easy to find one ). The cost of this is the fact
that some of them may be stored as two or more bytes. You have to remember that
when you choose CHAR(100) you are defining the storage space (100 bytes, not
100 characters)
The exceptions you get when you change the DB_LOCALE are caused (I'm assuming
this, please confirm), because you're just changing the value of DB_LOCALE. But
if you already have the database created (with a different DB_LOCALE at the
creation time), and you're using a recent version you'll have an error and the
connection is refused. The DB_LOCALE has to be the same during the lifetime of
the DB. The value at creation time specifies the LOCALE to use for this
database and this information is stored in sysmaster. IT CANNOT BE CHANGED
without recreation of the DB.
There is a server side variable that can change this behavior, but I would not
recommend it's use unless it's a temporary workaround and you realize the
implications.

Finally, why don't you use the polish character set as your databases LOCALE?
Do you need to store foreign characters? Or do you need foreign countries to
access it? Please don't tell me you're working on a Portuguese bank with
operations in Poland

If your problem persists you may consider contacting support... In either case,
a full description of IDS versions, real DB_LOCALE (available in
sysmaster:sysdbslocale table) environment etc. may be helpful.

P.S.: about the conversion subject above... There are situations where some
tools may have a permissive behavior, like converting all characters that don't
have representation in the destination codeset to a single character. This
means you'll never be able to recover the original character, so, in a sense,
we can consider this as data corruption. This behavior will change, or at least
will be controllable by an environment variable. I believe there is no version
available with this new behavior. This present behavior will vary with
different source and destination codesets.


Regards,

--
Fernando Nunes
Portugal

http://informix-technology.blogspot.com
My email works... but I don't check it frequently...