Fremdsprachen einführen

[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?

[andreaspr@aon.at]

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.

Einfach ein ... Create or Replace Table ... die Attribute von VARCHAR auf NVARCHAR ändern und DB macht den Rest für dich.

[Rainer Ross]

"Create or Replace", wobei dann eben alle Daten weg sind

für einen Kunden habe ich kürzlich eine Datei auf UTF8 umgestellt, das hat mit folgenden Schritten gut funktioniert

1) alte Datei

create or replace table mylib.myfile (                      
       Id           integer      not null default,             
       Language     char(02)     not null default,             
       Message      char(256)    not null default,  
       CreateDate   timestamp    not null default              
);

2) für das Feld Message CCSID 1208 eingefügt

create or replace table mylib.myfile (                      
       Id           integer      not null default,             
       Language     char(02)     not null default,             
       Message      char(256)    not null default  CCSID 1208,  
       CreateDate   timestamp    not null default              
);

3) mit Runsqlstm oder im ACS die SQL-Prozedur aufgerufen. Die Daten sind danach alle vorhanden und auf die neue CCSID 1208 umgestellt

4) Tschechische Daten mit Insert eingefügt

Bei Fragen könnt ihr gerne Kontakt mit mir aufnehmen

Herzliche Grüße

Rainer

[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!