Unicode Daten aus MSSQL in AS400 schreiben

[sugarkane1979]

Hallo zusammen!

Ich bin kein AS400-Profi und stehe vor einem Problem.

Wir übergeben aus unserem CRM (MSSQL) Personendatensätze in eine Tabelle auf der AS400. Gelöst ist das ganze mit dem CA ODBC\Linked Server und funktioniert mit deutschen Zeichen auch soweit sehr gut.

Durch eine Erweiterung sollen jetzt auch Datensätze mit slowenischen Sonderzeichen übertragen werden. Leider werden die Sonderzeichen im Greenscreen nicht richtig dargestellt.

Im ODBC gibt es ja die Möglichkeit Daten in eine andere Codepage zu übersetzen, leider finde ich keine brauchbare Anleitung dafür.

Kurz gesagt, wie mache ich im ODBC aus SQL Unicode-Zeichen die Codepage 870?

Danke für Eure Hilfe!

[Fuerchau]

Da hast du schlechte Karten, wenn die Zieltabelle auf der AS/400 nicht entweder 870 oder Unicode 13488 ist.
Am Greenscreen kannst du sowieso nicht beides gleichzeitig darstellen.

Ist die Zieltabelle 870 muss der Job, in diesem Fall der ODBC-Job (QZDASOINIT) auch mit 870 arbeiten (273 geht dann nämlich nicht).
Dies erreicht man mit der Anmeldung als User mit der richtigen Sprach-ID.

Da aber wohl der SQL-Server die Daten alle in einer Tabelle hat (ist ja schließlich Unicode) geht das nicht in einer einzigen Übertragung (bzw. mit einem Linked-Server).

Besser ist es da auf jeden Fall, Unicode auf der AS/400 zu verwenden.
Dies wird in RPGLE auch unterstützt, nur halt nicht auf 5250 und SCS-PRTF's.

[sugarkane1979]

Hallo, danke für Deine rasche Antwort.

Ich hab jetzt mal nachgeschaut, die Datei in die ich den INSERT machen will hat Codepage 273 hinterlegt. Da wundert es mich nicht wenns nicht klappt ...

Wenn ich meinen Übertragung splitte und die slowenischen Personendatensätze in eine neue Datei mit CCSID 13488 schreibe, müsste die AS400 die Zeichen ja richtig interpretieren weil Unicode. Von dort könnten sie ja dann mit einem Monitor ausgelesen und weiterverarbeitet werden (ist dann auch Sache von den Programmierern von Infor).

Liege ich da richtig?

[Fuerchau]

Das ist korrekt.
Was die Weiterverarbeitung angeht so wirst du Probleme haben, sobald ein Programm ohne Unicode auf die Daten zugreift.
Dann geht die CCSID wieder verloren, gewonnen hast du damit nichts.
An einem 5250-Terminal kannst du sowieso nur genau eine CCSID darstellen!

Wenn du Infor-XPPS hast, wird erst ab 4.0 Unicode unterstützt.

[sugarkane1979]

Na ich werde das mal vorschlagen und schauen was die von Infor dazu sagen. Falls das mit Unicode von Infor AS nicht unterstützt wird sollte es ja auch so gehen:

Einen AS400-User mit CP 870 anlegen und diesen für den ODBC-Zugriff zu verwenden und die Daten dann in eine Datei mit CP 870 zu schreiben. Dadurch müssten ja die Sonderzeichen auch erhalten bleiben.

Danke auf alle Fälle für die Hilfe, mir ist jetzt bewusst auf was man da alles denken muss :-)

[Fuerchau]

Zu bedenken ist auch, dass ein Programm Schwierigkeiten hat, Dateien mit unterschiedlichen CCSID's zu öffnen.
Steht der Job auf 870 und du öffnest eine 273-Tabelle wird alles in 870 umgewandelt, deine Umlaute werden dann falsch dargestellt!
Unter Umständen lehnt das OS den Open wegen Inkompatibilität der CCSID's sogar ab (war früher jedenfalls so, heute wird ggf. Unicode als Zwischenschritt verwendet, genau weiß ich das aber nicht).

[sugarkane1979]

Diese Problematik der Darstellung ist mir bewusst, ursprünglich sollten die Datensätze aus der Zieltabelle ja über eine Kennzeichnung in einem Feld von einem User mit CP273 oder CP870 ausgelesen und weiterverarbeitet werden. Das ist ja schon daran gescheitert, dass die slowenischen Sonderzeichen nicht korrekt eingefügt wurden (eben weil die Tabelle CP273 hinterlegt hat).

Dann wollte ich die slowenischen Sonderzeichen schon im SQL mit einem REPLACE in die Zeichen umwandeln wie sie auf der AS400 mit CP273 dargestellt werden. Ein User mit CP870 hätte sie dann richtig gesehen. Aber da hatte ich mit den Zeichen č/Č ein Problem, weil diese in der verwendeten SQL-Sortierung nicht vorkommen. Daher ist dieser Workaround leider nicht zielführend.