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

[Fuerchau]

Nein, das ist ganz normal!
CCSID's unterschiedlicher Sprachräume sind generell nicht kompatibel und werden bereits seit V2! abgelehnt. Dies liegt im Konzept der CCSID's begründet.
Möchtest du mehrere unterschiedliche Sprachen in einer Tabelle speichern bleibt dir Unicode (N[VAR]CHAR) nicht erspart.

Sprachräume sind z.B. durch ISO-8859-X definiert.

[KM]

Also wir haben V7R2 und da funktioniert's ohne Fehler.

Gruß,
KM

[schatte]

Also wir haben V7R2 und da funktioniert's ohne Fehler.

Gruß,
KM

Das ist ja interessant.
Ich habe mir nun auch zwei unterschiedliche V7R2 Maschinen gesucht.
Bei einer klappt es (TL16306) und bei der anderen nicht (TL15135).

Also schreibe ich die IBM mal an.

Danke und Gruß
Matthias

[Fuerchau]

TL16306 ist doch größer als TL15135, mach doch einen Update bevor du eine Meldung abgibst.
Wobei ich nicht weiß, wieso das ohne Meldung auf einmal funktionieren sollte. Dies führt doch zu viel größeren Problemen im Nachhinein.

[schatte]

Nein, das ist ganz normal!
CCSID's unterschiedlicher Sprachräume sind generell nicht kompatibel und werden bereits seit V2! abgelehnt. Dies liegt im Konzept der CCSID's begründet.
Möchtest du mehrere unterschiedliche Sprachen in einer Tabelle speichern bleibt dir Unicode (N[VAR]CHAR) nicht erspart.

Sprachräume sind z.B. durch ISO-8859-X definiert.

Die meisten Felder sind bereits mit GRAPHIC 13488 kodiert. Keyfelder habe ich jedoch immer noch mit SBCS definiert.

Trotzdem ist doch das nicht einheitliche Verhalten zwischen 273 und 1141 nicht in Ordnung.

[Fuerchau]

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.

[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