Umwandlung eines Schema von CCSID 273 in 1208 (UTF-8)

[Witaseck]

Vielen Dank Herr Fuerchau,

die 1208 ist eine Vorgabe des "Lieferanten".
Diese ist nicht so ganz nachvollziehbar, da alle vorhandenen Char-Spalten um den Faktor 4 verlängert wurden.
Die Zieltabellen sehe ich mit jetzt an.

Ansonsten wird alles auf SQL und CL umgestellt. Der Aufwand hält sich in Grenzen.

[Fuerchau]

Also 1208 als interne Datenbank vorzugeben halte ich für grenzwertig. Dies zeugt davon, dass da jemand keine Ahnung hat.
Ich kann mir ebensowenig vorstellen, dass ein Lieferant mir vorschreiben kann, wie ich meine Datenhaltung betreiben muss. Internationalität kann ich mit UTF16 praktischer erreichen.
Für den Datenaustausch kann durchaus UTF8 verwendet werden.

Selbst bei einem SQL-Server wird UTF8 nicht unterstützt.
Dafür gibts SQL-allgemeingültig den Typ N[var]Char(n), wobei n die Anzahl Zeichen und nicht Anzahl Bytes ist.
Jedes System, zumindest, die ich kenne, arbeitet mit dem Typ String in der Verarbeitung.
Dies betrifft alle aktuellen Programmiersprachen!
Der Typ String ist DB-entspechend NVARCHAR, mt der CCSID 1200 bzw. in der Nicht-IBM-Welt eben UTF16.
Daher wäre eher eine Vorgabe von UTF16 als von UTF8 verständlich.
Anmerkung: Den String mit UTF16 hat Microsoft im Betriebssystem mit Windows 98 eingeführt.

Betrachte alleine den Aufwand für SQL bzgl. der diversen Abfragemöglichkeiten:
Jeder "where" auf UTF8 muss zuerst in UTF16 konvertiert werden um damit arbeiten zu können.
Jeder substr muss in UTF16 konvertiert werden, da sonst nicht mit Position korrekt zugegriffen werden kann.

Wenn du in RPGLE mit %subst() zugreifst, erhältst du falsche Ergebnisse wenn du nicht vorher auf %UCS2() umwandelst.

Und zum Schluss die Außenkommunikation:
Bei ODBC-Zugriffen muss in UTF16 umgewandelt werden um den Typ String erhalten zu können, ansonsten sind es Binär-Daten wo der Empfänger wissen muss, dass er UTF8 noch umwandeln muss.

Wenn du Dateien austauschst (z.B. CSV, XML, JSON) kannst du eben problemlos für diesen Zweck in 1208 ausgeben. Beim Empfang dann automatisch von 1208 in 1200 konvertieren.

Auch beim Drucken/PDF-Erstellung kann automatisch in UTF8 konvertiert werden.

Wenn du per ACS-SQL-Script Daten ausliest, wird per JDBC(=ODBC) auf die DB zugegriffen und alle UTF8-Felder müssen in UTF16 umgewandelt werden, da du sonst nur native UTF8 erhalten würdest.
Export in Excel erfolgt ebenso im Typ String, also UTF16.

Du machst es dir insgesamt einfacher, wenn du in Programmen und der Datenbank mit UCS2/1200/UTF16 umgehst, das ist insgesamt weniger anfällig und stabiler und natürlich rein intern.

Und ich denke, es ist noch nicht zu spät.