Fremdsprachen einführen

[BenderD]

... wenn man denn bei den Daten weiß, wo sie herkommen und wie sie codiert sind, kann man auch eine Unicode View über die Daten stellen; bzw. das Unicode Feld zusätzlich führen und per Trigger erzeugen und konsistent halten. Die Anwendung selber bleibt dabei unberührt. Zu Deiner Ausgangsfrage: selbst bei zurückschreiben der gelesenen Daten bleibt der Inhalt in Hex erhalten solange man keine Eingaben in diesen Feldern macht.

D*B

[dschroeder]

Vielen Dank! Die Idee mit der View werde ich hier mal ansprechen.

[Fuerchau]

Nun ja, das mit den Sprachen verhält sich da etwas anders.
Die CCSID's werden zusätzlich in Sprachgruppen geführt. Diese sind dann mit Latin-1 bis inzwischen latin-15 aufgeteilt.
Alle CCSID's einer Latin-Gruppe lassen sich ohne Verlust hin und her konvertieren.
CCSID's unterschiedliche Latin-Gruppen führen bei der Konvertierung zu Verlusten.
Vor Einführung von Unicode konnte man z.B. zwischen 273 und 870 nicht konvertieren, der Open einer Tabelle schlug fehl.
Ab einem bestimmten Zeitpunkt wurde die Konvertierung wohl auf 2-stufig umgestellt, d.h., 1. Stufe in UCS2, 2. Stufe in Ziel-CCSID.
Solange man dann die Daten nur liest, ist es unkritisch.
Schreibt man die Daten zurück, werden sie nicht mehr korrekt zurückkonvertiert, da bei der Hin-Konvertierung Ersatzzeichen oder "?" verwendet wird. Sporadisch gibt es aber bei einigen CCSID-Kombinationen trotzdem was auf die Finger.
In ILERPG hat man halt das Problem, dass beim Lesen alle Felder die definiert sind (z.B. als DS), gefüllt und beim Update zurückgeschrieben werden.
In SQL kann man gezielt sich auf die Felder beschränken.
Übrigens ab irgendwann kann man beim Update in Free in Klammern die Feldliste angeben.