View Full Version : Fremdsprachen einführen
Ja, das ist problemlos, der Feldtyp ist "C".
Aber Vorsicht:
Bei Move/Eval/Prozeduraufrufen erfolgt ggf. eine automatische Konvertierung wenn die Arbeitsvariablen, Parameterschnittstellen nicht auf "C" angepasst sind.
Mit Like-Definition ist die Gefahr gering, Definitionen auf C-Ebene (außen rechts) müssen vermieden werden.
dschroeder
14-09-17, 13:31
Vielen Dank an alle. Ich werde jetzt mal ein paar Tests machen.
dschroeder
14-09-17, 16:39
Ich muss doch noch etwas fragen: Ein Kollege vertrat die Meinung, dass eine Umstellung auf DBCS wegen Fremdsprachen nicht immer notwendig ist. Die gängigen Sprachen (alle mit lateinischen Buchstaben, sowie die mit griechischen und kyrillischen Zeichen) müsste man mit den Single Byte Character Set abbilden können. (Klar: Japanisch geht dann nicht).
Wenn das so ist und ein spanischer Anwender gibt ein Zeichen ein, das unser deutscher Zeichensatz nicht kennt: Dann müsste ein deutscher Anwender ja ein Ersatzzeichen sehen. Wenn der deutsche Anwender das dann wieder speichert, macht er dem spanischen Anwender dann seine Daten kaputt?
... 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
14-09-17, 17:12
Vielen Dank! Die Idee mit der View werde ich hier mal ansprechen.
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.
Die Idee ohne Unicode auszukommen geht eingeschränkt natürlich auch, in dem man für jeden Sprachraum eine eigene Tabelle mit der gewünschten CCSID anlegt und die Daten dort pflegt.
Allerdings ist dann erforderlich, dass Tabelle, Job und Terminal alle mit derselben CCSID fahren, damit es nicht zu Darstellungsverlusten kommt.
dschroeder
15-09-17, 08:35
Nochmals danke. Ist ein sehr komplexes Thema. Mich würde interessieren, was andere IBM i Anwender machen. Es ist ja oft so, dass man weiß, was theoretisch die beste Lösung ist, dass man aber in der Praxis doch eine einfachere (bzw. bekannte) Lösung wählt. Habt ihr zum großen Teil wirklich eure Tabellen auf DBCS umgestellt?
Nachtrag:
Hier muss ich noch mal D*B recht geben.
Ich kann durchaus mehrere SBCS-CCSID's in einer Tabelle unterbringen (sowas schule ich auch), wenn man bestimmte Dinge berücksichtigt:
- zwischen DB und Job findet keine Umwandlung statt, wenn Job+DB-CCSID identisch ist oder der Job auf 65535 (*hex) steht
- Zwischen Job und DSPF/PRTF findet (ohne besondere Maßnahmen) keine Codewandlung statt
Also, Daten, die an einem 870-Terminal erfasst werden landen so binär auch in einer 273-DB.
Zu beachten ist lediglich, dass die Daten auch nur an einem 870-Terminal oder in einem 870-Spool korrekt wiedergegeben werden können.
Ich muss also ggf. zusätzliche Flags haben, um dies u.U. zu berücksichtigen (z.B. in einer View mit einem case-Verteiler für die Umwandlung in Unicode).
Wie Dieter schon sagte, solange ich die Daten nicht verändere werden sie binär betrachtet.
Beim Drucken muss ich dann berücksichtigen, dass ggf. beim Wechsel des Sprachflags eine andere PRTF (ggf. per OVRPRTF) mit anderer CHRID geöffnet werden muss.
Zu beachten ist dabei lediglich, dass auch die Drucker unterschiedliche Hardwarefonts unterstützen müssen.
@DSchroeder
Die einfachste Form ist tatsächlich Unicode!
Alles andere führt unweigerlich zu weiterführenden Maßnahmen, zumal man ja bedenken muss, dass ODBC-Clients per Default in Unicode arbeiten (außer alten C++-Anwendungen, die nicht explizit in Unicode entwickelt wurden).
Leider ist dann so, dass solche angedachten "einfachen" Lösungen dann durchaus viele Jahre Bestand haben.
Gerade hierzu hatte ich letztens ein Beispiel:
Die deutschen Umlaute sind in vielen Sprachwelten vertreten, haben aber immer wieder andere Codepoints. So ergab sich dereinst die Situation, dass in einer polnischen Niederlassung durchaus grenznahe deutsche Lieferadressen erfasst wurden.
Leider wurden dieselben Adressen auch von Deutschland benötigt, und eine Adresse gibt es halt nur einmal.
Bei den Anzeigen und Drucken viel dann immer häufiger auf, dass die Umlaute wiedermal falsch waren.
Erst nach Einsatz eines Triggers wurde dann festgestellt, dass in Polen und Deutschland die Adresse ständig korrigiert wurde.
Beim Einsatz von Unicode (auch mit 5250-Terminals) wäre das halt nicht passiert.