Zeichensatz/Sonderzeichen

[Fuerchau]

Das Thema CCSID's ist in diversen Beiträgen ausführlich beschrieben.

Um Daten aller Sprachräume gleichzeitig zu speichern, musst du UCS-2 (UNICODE, CCSID 13488) für die Datenbank nehmen.
An normalen 5250-Terminals (CA, Emulationen) lassen sich west- und osteuropäische Zeichen nicht gleichzeitig darstellen.

Wenn du in Java arbeitest, sind die Daten intern ja in UCS-2 gespeichert. Nur beim Datenaustausch per SQL kommt es zur Übersetzung und den damit verbundenen Verlusten wenn die Datenbank den Code nicht speichern kann.

[Deficiency]

Erstmal danke für die Schnelle Antwort!
Glaub mir oder nicht! Die Topics mit CCSID hab ich alle gelesen, sonst hätte ich ja net gepostet!
Also ich habe in der Tabelle Folgende Spalten
1. SQLCHAR typ CHAR
2. UC typ GRAPHIC CCSID 13488

Was du mit dem Terminal meinst ist mir noch nicht ganz klar!
Wir arbeiten PersonalCommunicatio AS400 Client AccessExpress vom IBM

Gibt es eine möglichkeit die Übersetzungsbedingten Verluste zu vermeiden???

Das Thema CCSID's ist in diversen Beiträgen ausführlich beschrieben.

Um Daten aller Sprachräume gleichzeitig zu speichern, musst du UCS-2 (UNICODE, CCSID 13488) für die Datenbank nehmen.
An normalen 5250-Terminals (CA, Emulationen) lassen sich west- und osteuropäische Zeichen nicht gleichzeitig darstellen.

Wenn du in Java arbeitest, sind die Daten intern ja in UCS-2 gespeichert. Nur beim Datenaustausch per SQL kommt es zur Übersetzung und den damit verbundenen Verlusten wenn die Datenbank den Code nicht speichern kann.

[Fuerchau]

Genau das ist ja das Problem:
In den verschiedenen CCSID's haben verschieden Hexcodes unterschiedliche Bedeutung (varianter Zeichensatz).
Im Gegnzug gibt es ein paar Zeichen (z.B. A-Za-z0-9), die als invariante Zeichen in allen CCSID's gleich ist.

Die CA-5250-Sitzung kann eben nur auf eine Host-CCSID (273, 870, usw.) eingestellt werden.
Bei der Ausgabe von CHAR-Daten erfolgt die Darstellung der Hexwerte eben in der eingestellten Schrift der 5250-Sitzung.
UCS-2 wird in die JOB-CCSID (die nicht UCS-2 sein kann) gewandelt mit den entsprechenden Verlusten und dann am Terminal angezeigt.

Daten eines 273-Terminals sehen eben anders aus als bei einem 870-Terminal.

Um dieses zu umgehen, muss man eben eine Client-Server-Anwendung schreiben, die die Daten aus der DB per SQL im UCS-2-Format liest und eben dann mit Windows-Methoden auszugeben.
Umgekehrt eben in Windows eingeben und per SQL im UCS-2-Format wieder in die DB zurückschreiben.

[Deficiency]

Das das nur so läuft hab ich mir fast gedacht, aber bis jetzt erfolgreich verdrängt!
Naja! mal gucken was daraus wird!

Nochmal vielen vielen Dank

Genau das ist ja das Problem:
In den verschiedenen CCSID's haben verschieden Hexcodes unterschiedliche Bedeutung (varianter Zeichensatz).
Im Gegnzug gibt es ein paar Zeichen (z.B. A-Za-z0-9), die als invariante Zeichen in allen CCSID's gleich ist.

Die CA-5250-Sitzung kann eben nur auf eine Host-CCSID (273, 870, usw.) eingestellt werden.
Bei der Ausgabe von CHAR-Daten erfolgt die Darstellung der Hexwerte eben in der eingestellten Schrift der 5250-Sitzung.
UCS-2 wird in die JOB-CCSID (die nicht UCS-2 sein kann) gewandelt mit den entsprechenden Verlusten und dann am Terminal angezeigt.

Daten eines 273-Terminals sehen eben anders aus als bei einem 870-Terminal.

Um dieses zu umgehen, muss man eben eine Client-Server-Anwendung schreiben, die die Daten aus der DB per SQL im UCS-2-Format liest und eben dann mit Windows-Methoden auszugeben.
Umgekehrt eben in Windows eingeben und per SQL im UCS-2-Format wieder in die DB zurückschreiben.