Wieder mal CCSID-Problem

[KM]

Vielen Dank für die umfangreiche Erläuterung !

Versuch es doch mittels der View, die bereits korrekt in UNICODE umsetzt. Oder besser noch, verwende JAVA auch zum Abfragen der DB (Grund siehe oben).).

OK. Das mit dem View funktioniert. Nur müsste ich diesen halt noch erstellen und dann manuell per MS-Query verarbeiten. Finde ich jetzt nicht so elegant.

Leider geht das ansonsten so nicht !!
Begründung:
Solange dein System ein SBCS-System ist (Singelbytecharacterset) muss ein Job auch mit einer SBCS-CCSID arbeiten.
Alle Jobs erfahren dann halt eine Code-Wandlung der Daten in die jeweilige CCSID (Ausnahme 65535!). Beim Schreiben der Daten werden diese nun wieder in die SBCS-CCSID der PF zurückgewandelt.)

Ich hatte meinen Job auf CCSID 1153 geändert. Trotzdem war das Ergebnis nicht das gewünschte.

Wie wir ja wissen, gibts zwischen Latin1/Latin2 im SBCS Verluste, die man nur mit DBCS (Doublebytecharacterset) ausgleichen kann. Da Excel nun mal im UNICODE (=DBCS 13488) arbeitet, wird nun mal der Hexwert eines SBCS-Jobs der entsprechenden DBCS-Stelle zugeordnet und somt die Codewandlung durchgeführt.

Korrekt kann das ganze nur funktionieren, wenn der Job der dies durchführt mit einer kompatiblen CCSID fährt.
Solange das System ein SBCS ist, kann ein Job keine DBCS-CCSID annehmen. Also ist er gezwungen die Daten so zu verarbeiten wie sie ankommen.
Bei CCSID 65535 (Job/Datei oder sonst wo) erfolgt keine Datenumsetzung der SBCS !
Die Anwendung (oder der User) muss also GENAU wissen, welche Daten angenommen werden sonst kommt es (wie so häufig) zum Datenchaos. Ich kann also duchaus Latin1-Zeichen in eine Latin2-DB schreiben und hoffen dass diese auch das nächste mal so zurückkommen, ggf ein ein anderer User den Wert an einem Latin2-Teriminal "korrigiert" und der Latin1-User wundert sich.
Auch beim späteren gemeinsamen Ausdruck / Download o.ä. ist die Eindeutigkeit der Zeichen nicht mehr gewährleistet

Also: Der Job muss mit seiner CCSID immer zur CCSID der DB UND der AUSGABE/EINGABE-Geräte passen !!!

Wie kann ich nun in einem Job Latin1 und Latin2 oder chinesisch, türkisch usw. verarbeiten ? ===> UNICODE 13488

Dazu muss das System aber auf DBCS umgestellt werden !!!
Die Programme müssen ihre Zeichenfelder als GRAPHIC-Felder verwenden, Zeichenkonstanten müssen als G'...' umgesetzt werden, usw. usw. usw., die Latte erscheint endlos.

Will ich das nicht, bleibt mir nur SQL (System bleibt SBCS) und die Variablen die ich benötige definiere ich als GRAPHIC !

Warum kann das System das nicht automatisch ?
Nun, mit welcher CCSID arbeitet denn dein Java-Job (im Batch) um mit der 1153 umzugehen ? Wahrscheinlich in 273 oder 1141 ! Und nun weißt du auch warum bei der Ausgabe in Excel die polnischen Zeichen verloren gehen.
Ändere den Job (keine Ahnung wie in Java) auf 1153 ! Dann müsste es gehen..)

Wie bereits erwähnt hatte ich meinen Job, den ich interaktiv aufrufe, auf CCSID 1153 umgestellt (= RPG-Programm, in dem ich Java-Methoden aufrufe). Deshalb wundere ich mich ja, dass die polnischen Zeichen verloren gehen. Denn Job und Datei stehen auf CCSID 1153.

Oder: Generiere den SQL mit casting in GRAPHIC, so dass dein Java bereits UNICODE bekommt.

Und zum Schluss !
Warum klappt UNICODE per ODBC aber 1153 nicht ?
Auch der DB-Server arbeitet mit SBCS und die CCSID wird auf Grund der installierten Primär-Sprache der AS/400 (Latin1/2) und nicht des PC's entschieden. Der PC ERWARTET also Latin1-Daten beim SBCS und wandelt diese in den PC-korrespondierenden UNICODE um und somit bleibt auch bei CP1252/CP1250 ein 273/1141-Ü immer ein Ü.

Das stimmt so nicht. ODBC kann 1153 umsetzen. Das hatte ich ja im letzten Beitrag bereits geschrieben. Da hatte ich meine Datei mit 1153 per ODBC-Abfrage in Excel geladen. Das hat funktioniert. Nur eben nicht voll automatisch.

PS:
Was ich noch nicht ausprobiert habe ist (seit V5R2) die direkte Angabe der CCSID im ConnectionString (ODBC-Registrierung->Umsetzung->Erweitert).

[Fuerchau]

Java läuft in einem eigenen Job und bekommt daher auch eine eigene CCSID, ich weiß allerdings nicht woher (vielleicht wieß es ja Dieter).

Warum kann dein Java-Programm denn nicht mit dem UNICODE-SQL arbeiten ? Dann benötigts du das Excel mit ODBC nicht.

Alternativ:
RUNRMTCMD bzw im Dialog per STRPCO + STRPCCMD und Ausführung des Excel-Sheets. Im Excel die Abfrage so definieren (Eigenschaften), dass beim Open des Excels die Abfrage aktualisiert wird.
Dann noch Automatisch Speichern beim Ende und schon läufts automatisch.