Fremdsprachen einführen

[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

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

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.

[Fuerchau]

@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.