CCSID Problem aufs Neue

[Fuerchau]

Da gibts wohl doch einige Probleme bei der CCSID(870) und der CHRID(959 870) !
Ich habe nun auch einiges getestet, aber das korrekte Ergebnis wird auf der AS bzw. vom Terminal (CA5250) nicht unterstützt.
Die einzig funktionierende Konvertierung ist von Codepage 1250 (Windows-Osteuropa) nach CCSID 870 (EBCDIC Osteuropa).
Allerdings können da einige Zeichen nicht korrekt dargestellt werden, da diese in der CHRID einfach nicht vorhanden ist.

Das Ergebnis aus

äÄöÖüÜß#?;šŠđĐčČćĆžŽ#?

ist mit Datei-/Job- und Display-CCSID:

äÄöÖüÜß#?;šŠdÐcCcCžŽ#?

Man beachte also den Darstellungsverlust.
Dies liegt nicht an den Daten, sondern einfach daran, dass in der SBCS-CCSID 870 eben die deutschen Umlaute auch vorhanden sind !

Meine Übertragungsmethode ist übrigens SQL mit ODBC.
Auch hierzu gibts einiges zu beachten:

In der Verbindungszeichenfolge gibts seit V4R? den Parameter CCSID=nnnn.
Mit dieser CCSID ist allerdings nicht die AS/400 gemeint, sondern in welcher Codepage der CLIENT arbeitet (Windows Europa läuft da normal mit 1252 ANSI).

Gibt man dort eine CCSID an, müssen die Daten in dieser Codepage angegeben werden.
Für obigen Fall habe ich den Wert also auf CSSID=1250 (Osteuropa) geändert und die Daten in eine PF mit CCSID(870) geschoben.
Alle anderen Methoden führten zu negativen Ergebnissen.

Auch folgendes sollte man wissen:

Wird ein SQL-Kommando direkt ausgeführt (also ohne Parametermarker) erfolgt die Umsetzung von UNICODE zu SBCS bereits im Client, also hier bereits mit Datenverlust.
Ausnahme, man bestimmt dass der gesamte SQL als UNICODE übergeben wird. Dies muss man allerdings in der Verbindungsfolge bereits angeben.
Um UNICODE per ODBC korrekt zu verarbeiten muss man alles in UNICODE machen.

Nun gibt es noch die Möglichkeit mit Parametermarkern zu arbeiten, also:
an Stelle von "insert into myfile values('Text')"
sollte man "insert into myfile values(?)"
verwenden. Normalerweise werden vom ODBC-Treiber alle Parameter entsprechend des Feldtyps automatisch erkannt und voreingestellt.
Aber alle String-Parameter sind GRUNDSÄTZLICH SBCS-Zeichenfolgen, also nix mit UNICODE.
Die Parameter können allerdings auf WideCharacter (adWChar, adVarWChar) geändert werden um auch tatsächlich UNICODE an die AS übertragen zu können.

Tue ich das eben nicht, also die Parameter auf WChar umstellen, erhalte ich absolut keine Chance UNICODE an die AS/400 zu senden.

Mit meiner neuen Version des ExcelAddin's Uplaod/400 (2.0), die ich demnächst ins Netz zum Download stellen werde, sind alle diese Probleme berücksichtigt und per Parameter einstellbar.
Eine kurze Beschreibung werde ich dann ins Software-Forum stellen.

Das Problem des Zeichenverlustes im obigen Beispiel läßt sich auch mit UNICODE nicht lösen, da nun mal die EBCDIC-CCSID(890) diese Zeichen nicht enthält.
Ob es eine andere CCSID gibt müsste untersucht werden, gefunden habe ich erstmal keine.

Noch eine kleine Anmerkung am Rande:
Man darf sich von VB/VBA nicht ins Boxhorn jagen lassen.
Strings sind Unicode und bleiben auch Unicode !
Gibt man allerdings Strings mit z.B. Debug.Print aus, werden diese in ANSI umgewandelt und können daher nicht mehr alles enthalten.
Auch die ASC-Funktion liefert keine Werte > 255, so dass man mit VB/VBA keine Chance hat den Inhalt zu prüfen.