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

[Fuerchau]

CCSID 1208 ist in der DB auch für Java kontroproduktiv.
In Java muss UTF8 erst in String konvertiert werden (UTF16 = CCSID 1200) um damit arbeiten zu können. Beim Schreiben muss wieder in UTF8 überführt werden.
Wenn die DB gleich UTF16 hat, wird sie auch vom JDBC-Treiber korrekt als String interpretiert.
Ein Automatismuss UTF8<=>String gibts da nicht.
Desweiteren muss man bedenken, dass man mindestens den doppelten bis 3-fachen Platz vorsehen muss, da UTF8 ein variabler Zeichensatz ist.
Bei UTF16 (n[var]char) ist die Längenangabe bereits in Zeichen und nicht in Bytes. Und zumindest lassen sich japanisch und chinesisch (1 Dialekt) in den ersten 32K-Zeichen unterbringen ohne auf 4-Bytes gehen zu müssen.
Ich hatte da mal ein Oracle-Problem, da auch dort mit UTF8 gearbeitet wird und die Länge dann in Bytes definiert wird. Daher wurde ein Feld "Lager" als nchar(2) definiert. Als dann auf dem Quellsystem ein Lager "Ü1" angelegt wurde, scheiterte die Schnittstelle, da nun 3 Bytes in 2 Bytes nicht passen.

Auch ist generell VARCHAR vorzuziehen und die Daten ggf. zu trimmen, da auch in Java Leerzeichen am Ende für Vergleiche relevant sind, für die DB allerdings nicht, wie für RPGLE und COBOL auch.

Da die DB zwar UTF8 mittlerweile selber unterstützt, passiert beim Lesen in RPG auch erst mal keine Umwandlung, da das Zielfeld ja ebenso mit CCSIID 1208 getagt sein sollte.
Nur bei der Weiterverarbeitung muss ich erst in CHAR oder UCS2 umwandeln, was der Einzelfeld-Eval ja tut. Ein Eval-Corr nimmt das Feld aber nicht mit, wenn die CCSID nicht identisch ist.

Der CPYF ist auf keinen Fall zu empfehlen.

[Witaseck]

Vielen Dank für eure Hinweise.
Wir haben die Aktion erfolgreich durchgeführt und für das Kopieren eine SQL-Schleife mit "insert into" genutzt.

[Witaseck]

Mit einigen alten QUERIES die per CL aufgerufen werden und dann in eine neue Tabelle schreiben (beispielsweise " STRQMQRY QMQRY(MUB/ZCMS_V03BK) OUTPUT(*OUTFILE) OUTFILE(MUBDAT/ZCMS_V03BK) ")
gibt es aber Probleme. Wir erhalten folgende Fehlermeldungen:
- Auswahl für Operator X'0001' ungültig. Ursachencode 7.
- Zeichenumsetzung zwischen CCSID 1208 und CCSID 65535 ungültig.
- Befehl RUN für Objekt QUERY mit SQLCODE -332 fehlgeschlagen.

Wir kann das Problem gelöst werden?

[RobertPic]

Unter welcher Job-CCSID läuft das QM-Query? CCSID 65535 heißt ja, ich hab das "Roh" gespeichert, weiß aber nicht welche Codepage das ist und nehme dann die vom Job an. D.h. der Job muss dann mit der richtigen CCSID laufen.

Habt ihr bei B.Hauser Weg noch geforscht? hat bei uns immer gut funktioniert.

[Witaseck]

Der Job läuft mit der System-CCSID 273 und alle verwendeten Objekte im QM sind vom Typ SQL.

[Fuerchau]

Das Problem ist hier tatsächlich das alte QM-Query, das neue Tabellen nicht per SQL sondern intern via DDS erstellt. QMQRY kennt CCSID 1208 allerdings nicht! Daher könnte die Ausgabetabelle mit 65535 (Binär) erstellt worden sein. Das kannst du mal mit DSPFFD verifizieren.
Im Wesentlichen läuft das darauf hinaus, alle QMQRY in SQL mit "create table ... as (select ...)" umzubauen. Solche SQL's kann man sich per ACS-Script erstellen und dann auch per RUNSQL, ggf. lesen aus Datei, direkt ausführen.
Ich weiß auch nicht warum ihr euch für 1208 statt 1200 entschieden habt.
Bei der Erstellung von 1208-Feldern sollte man auch immer mindestens die doppelte Anzahl Zeichen vorsehen, da 1208 eben variabel 1-4 Zeichen breit ist. Häufig zwar mit 2 Zeichen auskommt aber eben mehr Platz braucht als vermutet. Spätestens im interationalen Bereich mit vielen Sonderzeichen Accent, Umlaute usw. brauchts Platz.
CCSID 1200 (UTF16) wäre die bessere Alternative gewesen, und zwar in allen Belangen (ILERPG, Java, ODBC) Bei Java/ODBC wäre da noch nicht mal eine Umwandlung nötigt, da 1200 dem Typ String entsprincht.
Ggf. könnte QM damit auch besser umgehen.

[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.