Hello Barbara,
Am 29.08.2023 um 18:28 schrieb Barbara Morris <bmorris@xxxxxxxxxx>:
Again, this is only an issue with UTF-8 data in database files. There is no similar issue with UCS-2 and UTF-16 data in database files.
Why should one mess with UTF-8 in the i database then? As long as automatic conversion works towards the end user UI, I see no reason to introduce workarounds to prohibit any conversion just for the sake of "UTF-8 in the database"? To me, this smells quite a bit like the ever-touched-QCCSID issue.
As far as I know, this issue with UTF-8 in the database is an RPG issue, mainly due to the fact that RPG did not become "aware" of alphanumeric CCSIDs until V7R2.
Interesting remark.
I'm coming closer to the point facing a similar issue myself.
I have a bunch of DDS derived PFs with CCSID 1141 (EBCDIC + €), on a 7.2 machine. An external PHP application running on Linux uses ODBC to meddle with the data within. For some reason, the Linux side gets (and must send) Latin1. Modern browser based infrastructure wants to use UTF-8 exclusively. Because the PHP stuff must be reworked anyway, I was asked to help with the database side of affairs.
Now I'm contemplating which CCSID to give text database fields for new data tables, copying data with "insert into… select from" from the existing tables, and do automatic conversion to the right thing.
Looking at this:
https://www.ibm.com/docs/en/i/7.2?topic=encodings-fileencoding-values-i-ccsid
You said that UTF-8 in database files is (mainly) a problem because of RPG vs. alphanumeric CCSIDs. But from the table above I see UTF-8 is said to match CCSID 1208, which only has digits. Currently, the database PFs are used solely over ODBC. No local 5250 applications. Yet. Maybe someday this might become a thing.
May I kindly ask you to elaborate about this alphanumeric thing for RPG?
Thanks!
In addition, I was under the impression that there is a "UTF-8 EBCDIC" encoding. AFAIK UTF-8 low positions are ASCII compatible and I assumed there is a similar, backwards compatible entity for EBCDIC. Apparently I assumed wrong. :-)
One more thing… I can compile a PF with CCSID(1208) character fields to an object, but not CCSID(1200) which should be UTF-16 according to the above table. This fails due to CPD7678. The help text leaves me puzzled. Is this just a badly worded "not supported"? Which means my only meaningful option is CCSID(1208).
Thanks for helping. This topic is highly confusing.
:wq! PoC
midrange.com
