Zeichen konvertieren: deutsch <-> polnisch

[Fuerchau]

Eine Konvertierung zwischen Deutsch und Polnisch (273/870) ist definitiv nicht möglich!

Die Codepages sind "doppelt" belegt, also ein Hexwert in 273 stellt ein anderes Zeichen dar als der selbe Hexwert in 870 (ausgenommen natürlich der invariante Teil und ein paar andere Zeichen).

Möchtest du nun die Zeichen "neutral" in die DB schreiben, so musst du die CCSID 65535 verwenden.

Da dies in ODBC-Jobs aber nicht geht, da sonst nicht in ANSI gewandelt wird, musst du an den richtigen Stellen casten.

Nichts desto trotz ist dies die schlechteste Lösung, da es für die saubere Darstellung keine Garantie gibt.

Innerhalb der 5250 funktioniert das noch, da zwischen Device und Job keine Codewandlung durchgeführt wird, so dass man bei falscher Codepage des Device durchaus Schrott in die DB schreiben kann so lange am selben Typ Termnial aus Schrott wieder Darstellbares wird. An einem anderen Terminal bleibt es aber Schrott.

Eine Änderung des QZDA-Jobs auf eine andere CCSID hilft hier auch nicht, da beim Wandeln von 273 auf 870 nun Unicode "zwischengeschaltet" wird (früher wurde ein Open der Dateien wegen inkompatibilität abgelehnt) und der Selbe Verlust nun wieder auftritt.

[it99]

Vielen Dank für die schnelle Antwort.

wir haben uns schon überlegt, selbst eine Konvertierungstabelle zu erstellen. Dies ist natürlich nicht sehr performant.

Würde der Einsatz der iconv-API was bringen?

[Fuerchau]

Nein, wie willst du denn konvertieren?
Da du ja alles über Prozeduren regelst, hast du dich von den Möglichkeiten in SQL quasi entkoppelt.

Auf Resultsets von Prozeduren kannst du nicht mehr mit SQL einwirken!

Wenn du mit ODBC zugreifst, musst du folgendes Bedenken:
Windowsanwendungen arbeiten schon mal per se in Unicode. Übergibst du einen Unicodewert an einen SBCS-Parameter, wird hier schon mal von Unicode in SBCS übersetzt. Ist das Windows polnisch, bleibt ja erst mal alles beim Alten, ist das Windows deutsch, geht die polnische Darstellung verloren.
Nun ist der Parameter in ANSI und wird bei der Übergabe an deine Prozedur in die EBCDIC-CCSID des QZDA-Job's gewandelt. Spätestens hier geht dein polnisch aber verloren.

Du kannst versuchen, den QZDA-Job in CCSID 870 zu versetzen (entweder per Prozedur (eigene oder QCMDEXC) mit "CHGJOB CCSID(870)".

Zusätzlich musst du deine Selects in den Prozeduren aber casten "cast(mychar as char(nn) ccsid 65535)", dann betrachtet das System die Daten als "neutral" und wandelt nicht in die JOB-CCSID.
Ebenso ist beim Insert natürlich ein cast auf CCSID 65535 erforderlich.

Nun kann der QZDA-Job (bzw. der Treiber) von der Job-CCSID nach ANSI konvertieren.

Ein Aufruf von iConv hilft dir hier nicht, da der bereits zu spät ansetzt, deine Daten werden ja bereits beim Lesen konvertiert.

Prozeduren sollten keine Resultsets zurückgeben sondern nur gezielt einzelne (oder mehrere) Werte (OUT/INOUT-Parameter).
Sollte mehr Anwendungslogik nötig sein (ins besonders beim Insert) sind hier Trigger bzw. Constraints der richtige Ansatz.

Und zu guter letzt:
Sollte von polnischen Clients auf deutsche Daten zugegriffen werden, verlierst du halt die deutsche Darstellung, was spätestens bei einem Update deine Daten zerstört.

Am besten überarbeitest du deine Prozeduren und stellst diese auf Unicode um.

PS:
Ein CHGJOB CCSID(65535) hat auf SQL keine Auswirkung, im Zweifel nimmt SQL nämlich die Default-CCSID des Jobs und die bezieht sich auf die Primärsprache des Systems.

[Anton Gombkötö]

... sondern auch die betreffenden DB-Felder auf UCS-2 ändern.
Je neuer das Release, desto weniger Arbeit. (weil man sich sehr oft %UCS2 erspart)

[Fuerchau]

%UCS2 wirkt ja nur mit der JOB-CCSID!
Das Gegenstück %CHAR ebenso.
Wandelt man also von UCS2 in die JOB-CCSID hast du Datenverluste.
Wenn du diesen dann wieder mit UCS2 zurückwandelts hältst du diese Verluste auch noch consistent.

Das Ändern der DB macht natürlich Sinn, wenn du keine OPM-Programme mehr hast (oder sonstige RLA-Zugriffe, die UCS2 nicht unterstützen wie Query/400). Spätestens bei DSPF/PRTF ist allerdings einiges mehr zu beachten.

Ich meine so ab V6 ist S2 und %CHAR nicht mehr erforderlich, dass erkennt der Compiler dann automatisch.