Fremdsprachen einführen

[andreaspr@aon.at]

Müsste man die Hostvariablen im RPG dann auch mit dem Datentyp graph deklarieren?

Genau, du kannst aber auch ganz einfach eine extern beschriebene DS definieren. Dann brauchst du dir da keine Gedanken zu machen wie das genau definiert werden muss.
Nur wenn du die Unicode-Daten mit Chars kombinieren willst (EVAL oder IF) dann musst du halt Konvertierungen vornehmen (so wie in dem Beispiel was ich anfangs gepostet habe):

[dschroeder]

Wenn ich Unicode haben möchte: Wie soll ich mein Feld in der Datenbanktabelle deklarieren (graphic oder nvar oder ...).
Und wie ist dann der entsprechende Datentyp im RPG?

[Fuerchau]

Zukunftsorientiert NCHAR/NVARCHAR, die Notation ist da auch einfacher.
In ILERPG ist das immer Feldtyp "C" für UCS2.

[andreaspr@aon.at]

NVARCHAR.
Und die Variablen wie in meinem ersten Beispiel. Aber am besten mit Ext. DS.

[BenderD]

- in jedem Fall sollten die alpha keyfelder alpha bleiben und sich vom Inhalt her tunlichst auf den Kern aller CCSIDs beschränken. Es gibt nichts unangenehmeres als Key Felder, die gleich aussehen, aber nicht gleich sind.
- ich würde mir alle BigBang Szenarien ersparen und mir vorher ausreichend Gedanken machen, wie man die alte Welt im ViewLayer darstellt, damit Umstellungen und Programm Anpassung voneinander entkoppelt sind.

D*B

[dschroeder]

OK. Auch an dich vielen Dank, Dieter.
Das alles heißt für mich: Wenn ich ein Feld in der Datenbanktabelle als Unicode definieren will, muss ich überall, wo ich mit dem Feld arbeite (im DSPF, im RPG-Programm, in SQL-Anweisungen) berücksichtigen, dass das Feld Unicode ist. Für neue Felder, die noch nirgendwo im Einsatz sind, könnte man das eventuell mit vertretbarem Aufwand machen.

Wenn ich unsere gesamte Anwendung Unicode fähig machen möchte, ist das schon ein richtig großes Projekt.

[Fuerchau]

"Wenn ich unsere gesamte Anwendung Unicode fähig machen möchte, ist das schon ein richtig großes Projekt."

Nicht nur das, du solltest dich dann aber auch von DSPF und PRTF verabschieden und andere Ein-/Ausgabeformate verwenden.
Denn das Problem wird immer sein, da DSPF Unicode nicht wirklich unterstützt, dass Datenverluste in der Anzeige auftreten können und beim Zurückschreiben aus der DSPF dann bis zur Datenbank durchgereicht werden.

Meine Wenigkeit (und Dieter bestimmt auch) bieten dazu auch Workshops an;-).

[dschroeder]

Danke für das Angebot. Ich denke, wenn wir die komplette Umstellung durchziehen wollen, ist eine externe Beratung sehr sinnvoll.
Ich habe erstmal genügend Infos gesammelt, um das Thema bei uns im Haus weiter diskutieren zu können.
Nochmals herzlichen Dank für alle Antworten.
Schönes Wochenende!

[BenderD]

OK. Auch an dich vielen Dank, Dieter.
Das alles heißt für mich: Wenn ich ein Feld in der Datenbanktabelle als Unicode definieren will, muss ich überall, wo ich mit dem Feld arbeite (im DSPF, im RPG-Programm, in SQL-Anweisungen) berücksichtigen, dass das Feld Unicode ist. Für neue Felder, die noch nirgendwo im Einsatz sind, könnte man das eventuell mit vertretbarem Aufwand machen.

Wenn ich unsere gesamte Anwendung Unicode fähig machen möchte, ist das schon ein richtig großes Projekt.

... ich glaube wir sind noch nicht auf dem Punkt. Man muss die Umstellung entzerren:
Schritt 1: kompletter RLA raus alles auf SQL umstellen (dazu streite ich mich gerade mit ein paar Amis in der modrange-l)
Schritt 2: Alle Zugriffe auf Tables ersetzen durch View Layer, alle externen DS umstellen auf das View Layer
Schritt 3: zufügen der benötigten Uni Code Felder, Pflege über Trigger, Datenübernahme mit füllen der abgeleiteten Felder. Das bisherige View Layer bleibt unverändert!!! Alle Anwendungen merken davon nix, aber die Daten sind bereits in UniCode vorhanden!!!
Schritt 4: Erstellen zusätzlicher Views mit Uni Code Feldern anstatt der "alten Felder"
---- Ab hier kann man mit neuen Funktionen bereits auf die UniCode Felder zugreifen
Schritt 5: Überarbeitung des alten View Layers
-- umhängen der Felder auf die Unicode Felder mit Cast (case construct vonnöten)
-- instead Trigger für die Schreiboperationen
Die Altanwendung merkt immer noch nix bedient aber bereits die neuen Daten!!!

Ab jetzt kann man bei Änderungen vorhandener Programme Stück für Stück vom alten auf das neue View Layer umstellen. Ab einem gewissen Punkt kann man anfangen darüber nachzudenken, ob man das alte View Layer loswerden will.

D*B

[dschroeder]

Hallo Dieter,
vielen Dank. Ich bin wirklich ein Fan von Step by Step Anleitungen. Hört sich sehr brauchbar an.
Wir werden hier jetzt mal weiter darüber beraten.

[Fuerchau]

In Ergänzung könnt ihr noch einen Blick auf folgenden Thread werfen:
http://newsolutions.de/forum-systemi...488#post102374

Mein letzter Post beschreibt, wie man mit der ClientSolution-5250 und Unicode nun die gleichzeitige Darstellung verschiedener Sprachräume auf einem Bildschirm erreicht.
Für die PRTF's gibt es da ja schon länger was, wenn man AFPDS erstellt und als Schrift für ein UCS2-Feld einen Opentype-Font mittels FONTNAME auswählt und dann z.B. PDF's erstellen lässt.
Ob die diversen Spooltools auf dem Markt nun damit zurechtkommen, bleibt halt auszutesten.