View Full Version : Kompatiblität der CCSIDs 273 und 1141 / Probleme mit SQL
Es ist ja nicht nur die eigene Anwendung.
z.B. haben wir als Primärsprache 2984 installiert. Die Systemtabellen haben dann die CCSID 28709. Wenn ich nun meinen Job auf CCSID 1153 (PLK) stelle und anschließend:
SELECT * FROM systables WHERE SYS_TNAME = 'CCSIDTST'
bekomme ich auch wieder den Fehler:
Character conversion between CCSID 28709 and CCSID 1153 not valid.
Das ist ja genau das Problem mit den CCSID's.
Die Jobs müssen zur Laufzeit natürlich immer die passende CCSID des Systems aufweisen oder können allenfalls *HEX sein.
Die 1153 (Latin-2) ist nun mal leider nicht kompatibel zu 28709 (Chinesisch).
Ein Ändern der CCSID deines SQL-Serverjobs hat noch zusätzlich fatale folgen:
Nach Erstellung eines Result-Sets greift der ODBC/OLEDB/JDBC-Server wiederum auf die QSYS2-Objekte zu um die korrekten Felddefinitionen des Resultsets zu erfragen.
Hier scheitert der Server dann aber an der falschen CCSID.
M.a.W:
Mischungen von unterschiedlichen CCSID's auf einem System sind äußerst schwierig zu behandeln.
Die einzige Alternative ist wirklich Unicode oder entsprechende Casts in Unicode beim Select (View).
Bei Updates hast du dann ggf. schon wieder probleme, wenn du die Automatismen von .NET o.ä. verwendest, da du jeden Wert explizit in die korrekte CCSID casten musst:
select cast(My1153Field as nvarchar(nn) ...
update My1153File set My1153Field = cast(MyUnicodeValue as char(nn) ccsid 1153) ...
Was passiert denn wenn Du 'CCSIDTST' explizit auf die erwartete CCSID oder auf eine CCSID 13488 oder CCSID 1200 castest?
Birgitta
... ich tippe mal eher auf eine fehlende *TBL zur Umsetzung.
D*B
@Dieter
Im SQL sind die TBL-Objekte nicht mehr relevant. Dies wird komplett im System geregelt.
Wie soll denn die AS/400 aus den chinesischen Zeichen (28709) ggf. Latin-2 Zeichen (1153) extrahieren, vor allem, wenn sie im chinesisch nicht vorkommen?
Zum Zeitpunkt des Vergleiches der CCSID's kann das System nicht entscheiden, dass man nur auf invariante Zeichen selektiert.
Immerhin wird durch den Optimizer automatisch für Konstanten eine interne Hostvariable generiert.
Gerade für SQL gilt das selbe wie für native (naive) Zugriffe per RLA:
Die Job-CCSID muss zur Systemumgebung passen!
Beim embedded SQL habe ich das Problem nicht, so lange der Zugriff auf die QSYS2-Tabellen nicht erforderlich ist. Allerdings wird der eingebettete SQL ja ggf. wieder gegen die Tabelle-Definitionen geprüft (Feldvorhanden, Zugriffspfade für Indexoptimierungen usw.). Wie soll SQL dann die Namen ermitteln?
Spätestens aber bei der Verwendung von Prozeduren/Funktionen werden diese in den SQL-Tabellen gesucht. Bei falscher CCSID des Jobs gibts entweder obige Fehlermeldung oder die Namen werden nicht gefunden. Beides führt aber leider zu negativen SQL-Codes.
Bei Remote-SQL (also QZDASOINIT, CLI) greift der ODBC-Treiber grundsätzlich auf die Systemtabellen zu und gerade dann muss die CCSID passen.
Deshalb halte ich das Funktionieren unter TL16306 eher für einen Bug als ein Feature!
... was gegen Deine Annahme spricht ist, dass sich 273 nach 1025 casten lässt und 1141 nicht!
Wie immer der cast bewerkstelligt werden mag, es spricht sehr viel dafür, dass er über externalisierte "Tabellen" geht - ob das nunt *TBL ist, weiß ich nicht (und interessiert mich eigentlich wenig), es spricht aber einiges dafür.
D*B
Wir wissen ja beide, dass IBM da oft "vergesslich" ist.
Ich habe nun nicht so viel Möglichkeiten. Wer weiß denn genau, wie sich da IBM verhält.
Auf einem V6R1-System mit deutscher Sprache habe ich ebenso keine Probleme beliebige CCSID's per CHGJOB oder SQL-CAST zu verwenden (kein Wunder dass alle Probleme haben, wenn es keine Fehlermeldung mehr gibt).
Aber anscheinend verhält sich das System anders, wenn die Primärsprache eine DBCS-CCSID hat.
Dieses konnte ich noch nie testen.
In einem meiner älteren Posts (ich weiß nicht mehr wo) hatte ich auch festgestellt, dass das System im Zweifel intern über Unicode geht. D.H. CCSID1 => UCS2 => CCSID2. Dies geht halt immer.
Mein ursprüngliches Problem bezog sich ja auf Job-CCSID 1025 und Feld-CCSID 1141.
Das Problem hat ja erstmal nichts mit der Primärsprache des Betriebssystems zu tun, da es ja auch auf einem anderen System mit Primärsprache 2929 nachstellbar ist.
Als Workaround zur Codepage 1025 empfiehlt die IBM die Nutzung der Codepage 1154 (Cyrillic Multilingual with euro). Damit ist mein Problem gelöst.
Vielen Dank an alle.