UCS2 oder graph?

[dschroeder]

Hallo,
ich muss nochmal auf mein Thema mit den Zeichensätzen zurückkommen. Wir möchten ja einige Felder so deklarieren, dass man besondere Sprachzeichen (z.B. polnische Sonderzeichen) speichern kann.

In den DDS-beschriebenen Tabellen haben wir das entsprechende Feld jetzt so definiert:


A AD_L_ANSPR 60G TEXT('Ansprechpartner')
A CCSID(1200)


In den SQL-beschriebenen Tabellen ist das mit NVAR definiert:


sp_valuew nvarchar(1000) not null with default ' ',


Laut DSPFFD scheinen die beiden Definitionen den identischen Zeichensatz zu verwenden, nämlich 1200.

Wir rätseln jetzt aber, wie wir das im RPG am besten machen. Wenn wir die Felder im RPG z.B. als UCS2(1000) deklarieren, zeigt die Wandlungsliste die CCSID 13488 an. Wäre es besser, die Felder im RPG mit graph(1000) zu deklarieren?

Wir sind auf Probleme gestoßen, wenn wir die Deklaration mit graph machen. Dann bekommen wir bei Zuweisungen, für die eine Konvertuierung erforderlich ist, folgende Meldung:


g#_l_plz = f1.l_plz;
RNF0659: Implizite Zeichenfolgeumsetzung wird für Operand
G#_L_PLZ mit CCSID *GRAPH:*IGNORE nicht unterstützt.


Wir würden die implizite Umsetzung natürlich gerne nutzen. Müssen wir dann die Compile-Optionen umstellen?

Im Voraus schon mal vielen Dank.

Dieter

[Fuerchau]

In der Datenbank ist es quasi egal, wobei eben neuer N[VAR]CHAR bzw. Graphic 1200 besser zu verwenden ist.
In ILERPG wird ein Unicode-Feld immer als "C" definiert, wobei es da unerheblich ist, ob da 1200 oder 13488 steht. Dies wird mit UCS2 erreicht (oder eben "C"). *GRAPH ist nicht UCS2 und bedarf dann spezieller Kodierungen.
Noch ein weiterer Vorteile der CCSID 1200:
Diese wird von der DSPF und somit der 5250 unterstützt.
In der klassischen CA allerdings nur SBCS im Client, in der ClientSolutions-5250 mit Aktivierung von Unicode sogar vollumfänglich Unicode, also gleichzeitige Darstellung aller Zeichen bei Verwendung eines Unicode-Fonts. Die CCSID 13488 führt da zum Absturz (anderer Thread).

Ansonsten sollte man mit einem Repository (wie DDS REFF, Externe DS Template) arbeiten um alle Definitionen per LIKE davon abzuleiten.

[dschroeder]

... wobei es da unerheblich ist, ob da 1200 oder 13488 steht.


Ist das wirklich OK? (Bitte entschuldige meine nervige Nachfragen). Wenn wir im RPG 13488 nehmen und in der Datenbank 1200 steht, gibt es ja sicherlich irgendwo Differenzen, sonst wären beide CCSIDs ja gleich. Kann man mit RPG 1200 gar nicht implementieren?

Mir geht es darum, dass wir ja gerade ganz neu in das Thema einsteigen. Wir möchten da keine unnötigen Kompromisse eingehen, die uns später vielleicht mal ärgern.

Dieter

[Fuerchau]

In RPG sind 1200 und 13488 gleichwertig, wenn als Feldtyp "C" verwendet wird.
1200 = UTF16, 13488 = UCS2, wobei im RPG grundsätzlich nur UCS2 verwendet wird.
In der DSPF wird 1200 nun auch von der ClientSolution-5250 voll unterstützt, während die alte 5250 i.W. nur SBCS kann und daher eine Umwandlung von/nach 13488 oder 1200 erfolgt.
Das selbe gilt für PRTF's, hier muss man nur per FONTNAME eine UCS2-fähige Schrift wählen (Schriften mit Codepoints jenseits von 255).
Und im ODBC/JDBC-Umfeld wird (bis auf wenige Ausnahmen) grundsätzlich mit Strings in UCS2 gearbeitet. Nur für Transportzwecke (Datei, Netzwerk) wird u.U. von/nach UTF8 gewandelt.

[dschroeder]

Vielen Dank Baldur! Dann werden wir auf dem eingeschlagenen Weg bleiben und im RPG UCS2 verwenden.

[Fuerchau]

Real hast du in ILERPG sowieso keine anderen Chance ohne ständig Konvertier-API's (iConv) zu bemühen.