Kompatiblität der CCSIDs 273 und 1141 / Probleme mit SQL

[schatte]

Ich hatte mich auf dieses bezogen:
"Zeichenumsetzung zwischen CCSID 1141 und CCSID 1025 ungültig."
Bei 13488 gibt es keine Probleme!
Wenn du auf 273 eine Abfrage mit z.B. Umlauten und 1025 machst, gibt es ähnliche Probleme.

In den Alphafeldern sind nur Zeichen enthalten, die in allen EBCDIC Codepages enthalten sind. z.B. der Jobname oder der Username.
Das es Probleme gibt (Hex 3F, ...), wenn CCSID abhängige Zeichen abgefragt oder geschrieben werden, ist schon klar.

Ich wundere mich darüber, dass 273 klappt und 1141 nicht. Aber anscheinend hat die IBM hier schon irgendwas gemacht, jedenfalls in V7R2.

[KM]

Ich wundere mich darüber, dass 273 klappt und 1141 nicht. Aber anscheinend hat die IBM hier schon irgendwas gemacht, jedenfalls in V7R2.

Wir haben auch TL16306. Deshalb scheint es bei uns zu funktionieren. IBM hat da wohl wirklich schon was gemacht. Die invarianten Zeichen werden alle ganz normal angezeigt. Und die varianten Zeichen werden in der Anzeige durch etwas nicht darstellbares ersetzt. Insofern ist das schon alles korrekt so.

Gruß,
KM

[Fuerchau]

Unschön ist es insofern doch, dass inkompatible CCSID's (DB vs JOB) nun akzeptiert werden.
Dies wird unweigerlich zu Datenproblemen führen, es sei denn, dass ein Update dann auf jeden Fall ausgeschlossen wird. Man kann dann leider sehr schnell Daten fremder CCSID's unbeabsichtigt zerstören!
Dies hat eben die obige Meldung wegen inkompatibler CCSID verhindert.

Sobald mehrere CCSID's benötigt werden, also im Prinzip Mehrsprachigkeit in der DB kommt man um Unicode nicht herum. Spätestens bei Client-Anwendungen (Java, .NET) stellt das doch überhaupt kein Problem dar.
Ich weiß gar nicht, warum man immer mit aller Gewalt Unicode verhindern will um parallel deutsch und russisch in einer Tabelle zu speichern.
Langfristig tut ihr euch damit keinen Gefallen.
Ich habe einem Kunden schon mal gesagt, dass die ständigen Adressänderungen zwischen polnischen und deutschen Terminals eben in der Nichtverwendung von Unicode begründet sind.

[schatte]

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.

[Fuerchau]

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

[BenderD]

... ich tippe mal eher auf eine fehlende *TBL zur Umsetzung.

D*B

[Fuerchau]

@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!

[BenderD]

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

[Fuerchau]

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.

[schatte]

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.

[schatte]

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.

[B.Hauser]

Was passiert denn wenn Du 'CCSIDTST' explizit auf die erwartete CCSID oder auf eine CCSID 13488 oder CCSID 1200 castest?

Birgitta