Fremdsprachen einführen

[Fuerchau]

Also ja und nein:
Wenn du alle Dateien mit DDS erstellt hast und diese grundsätzlich mit einer REFF definierst, musst du nur die REFF anpassen.
Hast du keine REFF must du die Felder anpassen. Anschließend alle Dateien mit CHGPF umsetzen. Die Daten bleiben dabei erhalten.

In SQL gibt es das leider so nicht. Hier gibts es nur einen "Create or Replace", wobei dann eben alle Daten weg sind. Du musst dann halt Sripte erstellen, die statt dessen einen "Alter Table ... Alter Column set data-type ..." generieren.

[dschroeder]

OK, habe ich verstanden. Letztlich müssen also die Felder in den Tabellen auf graphic oder ähnlichem stehen. Wenn wir Unicode wollen, müssten wir (in einer SQL-Tabellendefinition) also "graphic(xx) ccsid 13488" stehen haben.
Wenn wir das hätten, könnten unsere RPG-Programme dann damit einfach so arbeiten, wenn alle Zugriffe auf diese Felder mittels embedded SQL laufen? Müsste man die Hostvariablen im RPG dann auch mit dem Datentyp graph deklarieren?

[Fuerchau]

Um ggf. keine Fehler zu erhalten sollte dies gemacht werden.
Wie Dieter schon sagte:
Wenn es ein Umsetzungsproblem UCS2 => SBCS gibt, setzt SQL ein Warningsflag in der Anzeiger-Variablen (NULL-Flag = -2). Arbeitest du ohne NULL-Anzeiger gibts einen negativen SQL-Code.
Jetzt kannst du dir ja selber ausrechnen, was beim Lesen und Update dann so alles passieren kann.
Wobei bei einer Where-Klausel ggf. keine Daten gefunden werden, da die Umsetzung beim Lesen zu Ersatzzeichen geführt hat.

Auch hier sollte man dann mit externen Template-DS der Tabellen arbeiten (Copy, Include) und alle abgeleiteten per LIKE definieren.

[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