German special Umlaut in UTF-8 DB
Marcus Haarmann could not store the capital sharp-s character in a DB_LOCALE=de_de.UTF8 database on IDS 14.10FC11; LOAD failed with error 847. Maneshkumar Sivalingam and Andreas Legner suggested GL_USEGLU=1 (ICU), which requires creating the DB, server and applications with it. Marcus said that was impractical for his admins and asked about NEWNLSMAP/NEWLOCALE. Unresolved.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
Hi all,
since 2017 the committee of German spelling has accepted a definition of a new character , which is a
uppercase variant of ß (sharp s).
We recently ran into an issue to store this special character in a database (DB_LOCALE=de_de.UTF8).
Firstly, we had the suspicion that our Java code was not able to handle the character, but it seems the IDS
cannot store this character (tried with dbaccess directly, IDS 14.10FC11).
Is there any workaround for this ? (other than enforcing lowercase for the ß everywhere ...) ?
Steps to reproduce (on my machine, Ubuntu 22.04):
(needs a UTF-8 terminal, LANG=de_DE.UTF-8)
create an empty DB with DB_LOCALE=de_de.UTF8, set CLIENT_LOCALE to same value
create a text file test.unl with the following content:
|
sql script:
create table test (test varchar (20)); - (char (20) does not work as well, same as nvarchar))
load from test.unl insert into test;The statement breaks with the following error:
Unknown error message 0.
847: Error in load file row1Bug or feature ?
Best,
Marcus
can you please set export GL_USEGLU=1 and then run 'Load' statement. ------------------------------ Maneshkumar Sivalingam ------------------------------
I'd not call it a bug, but probably a shortcoming of Informix' own GLS utf8 code set. By using GL_USEGLU environment, you'd enable ICU libs including more up-to-date code set. But for this to work you'd have to create the utf8 db with the server running with this GL_USEGLU environment run the server with this environment going forward run the application with this environment as well Any utf8 db having been created without GL_USEGLU set would no longer be accessible (unless server starts without the environment in which case GLU utf8 dbs would no longer be accessible.) HTH, Andreas ------------------------------ Andreas Legner Informix Dev HCL Software ------------------------------
Hi Andreas, thanks for the hint. I don't think that would be an option for our admins (which would need to unload/load all UTF8 DBs in a separate instance and we need to modify all existing datasource definitions when these are UTF-8). This is documented, but relatively hidden in the clientsdk. Since our code is accessing the DB via JDBC, I was expecting this environment in the JDBC environment definitions, Would NEWNLSMAP and NEWLOCALE/NEWCODESET be an approach to implement a valid mapping ? (User defined locales ...) Best,