Re: Informix .NET and Polish locale (required help)

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@gmail.com wrote: > 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 ! > 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...