Umwandlung eines Schema von CCSID 273 in 1208 (UTF-8)

[Witaseck]

Hallo zusammen,

kann auf der i5 ein Schema von der CCSID 273 in die CCSID 1208 "transformiert" werden?
Wir haben 2 Verfahren durchgeführt.


Verfahren 1 ist auf einer Testmaschine anscheinend erfolgreich abgeschlossen worden.

1.	Restore des produktiven Schemas z als x_273
2.	Reduktion der x_273 auf Tabellen und Katalog-Views
3.	Anpassung der SQL-Katalogviews des Schemas x_273 per SQL
4.	Löschen der TAD310DA1 per SQL "drop TAD310DA1 cascade"
5.	Neuanlage des Zielschemas z und der Tabellen (mit dem bisherigen Namen) per SQL
6.	Kopieren aller Daten per CPYF FROMFILE(x_273/xxx_S00005) TOFILE(z/zzz_S00005) MBROPT(*REPLACE) FMTOPT(*MAP)
7.	Wiederanlage von Constraints etc.

Verfahren 2 wurde produktiv verwendet und macht in einem JAVA-Programm Probleme (zum Beispiel bei decimal gezont 15stelligig ohne Nachkomma:
Exception: java.lang.NumberFormatException
Message: High-order nibble of the byte at array offset 293 is not valid. Byte value: 20
):

1.	Reduktion von Schema z auf Tabellen und Katalog-Views
2.	i5-Objektumbennnung (per RNMOBJ) von z auf x_273
3.	Anpassung der SQL-Katalogviews des Schemas x_273 per SQL
4.	Neuanlage des Zielschemas z und der Tabellen (mit dem bisherigen Namen) per SQL
5.	Kopieren aller Daten per CPYF FROMFILE(x_273/xxx_S00005) TOFILE(z/zzz_S00005) MBROPT(*REPLACE) FMTOPT(*MAP)
6.	Wiederanlage von Constraints etc.

Hat jemand von euch hier Erfahrungswerte?
Gibt es eine erprobte andere Vorgehensweise?


Mit freundlichen Grüßen
Axel Witaseck

[mk]

HI,

ich bin jetzt nicht der 100% Profi,
aber bei numerischen Werten spielt der Zeichensatz keine Rolle.

Wir legen unsere SQL Tabellen in NVARCHAR an ( CCSID 1200 ) und nicht in UTF-8

[Fuerchau]

Die einfachere Variante ist eher pur SQL.
Wenn die Struktur (Spaltennamen, Anzahl und Reihenfolge) der Tabellen ja identisch ist, kann nach dem Create ein simpler "insert into newschema.tablename select * from oldschema.tablename" angewendet werden. Das kann genauso gut auch per RUNSQL in CLP/CLLE erfolgen.

Zoned-Variablen müssen Zoned bleiben oder können auch in decimal konvertiert werden, da sie in SQL sonst nicht als Zahl verwendet werden können.
In Java lassen sich Zahlen i.W. nur als BigDecimal oder eben double/float verarbeiten.

Und ja, für RPGLE und SQL ist NVARCHAR praktischer (CCSID 1200 ist da der Default), da sie in ILERPG in UCS2 zur Verfügung stehen und bei der Remoteverarbeitung (SQL/ODBC/JDBC) der Typ String damit dargestellt wird und somit keine Umwandlung UTF8<=>1200 bei der Verarbeitung erfolgen muss.

[B.Hauser]

Ich würde das nochmals anders machen!
1. Über Reverse Engineering die SQL Erstellungsstatements (wichtig CREATE OR REPLACE TABLE!) generieren.
2. In den SQL Scripts Die CCSIDs in den Spalten umsetzen, also von 273 auf 1208
3. Die CREATE OR REPLACE Statements ausführen (die Umsetzung erfolgt automatisch).
Kopieren oder an den Catalog-Daten herumfummeln ist nicht nötig (und so wie so kritisch zu betrachten).
Ebenso müssen auch keine abhängigen Objekte erstellt werden.

Anmerkung: Falls Ihr mit RPG arbeitet könnten die UTF-8 Spalten größere Probleme bereiten. RPG konvertiert per Default die Daten den Tabellen in die Job-CCSID. Das ist vielleicht heute noch kein Problem, aber vielleicht in Zukunft. Nicht konvertierbare Zeichen werden durch Substitutions-Zeichen ersetzt. Ebenso arbeiten alle RPG String per Default auf Byte-Ebene. Wenn jetzt ein Zeichen mehr als ein Byte benötigt gibt es Probleme.

[Witaseck]

Hallo Frau Hauser,

vielen Dank für die Rückmeldung.
Alles läuft ohne RPG, es ist eine JAVA-Anwendung
("Dialog läuft auf Tomcat-Server").

Das alte Schema mit den modifizierten SQL-Katalogviews wird nur für den CPYF
(arbeitet ja mit den Systemnamen der Tabellen) benötigt und wird dann gelöscht.

Wie kommen dann die Daten vom alten ins neue Schema?

[Witaseck]

Hallo Herr Fuerchau,

das mit dem SQL wäre eine gute alternative zum CPYF.

[Witaseck]

Das sollte so sein, aber bei der 2. Methode kommen Fehler auf echte Zahlenspalten.

[BenderD]

Das sollte so sein, aber bei der 2. Methode kommen Fehler auf echte Zahlenspalten.

... das würde ich mal eher für einen Fehler des JDBC Treibers halten. Trotz desto nichts muss das Gefummel des Repositoties und der CPYF da raus.

D*B

[BenderD]

... dummerweise hat die Eier Variante von DB2 kein Alter Schema für den rename und der save restore funktioniert wohl nicht so, wie er sollte, sonst wäre das Repository der _xyz Variante korrekt. Da würde ich als erstes mal einen software defect melden.

Grundsätzlich gilt erst einmal: man habe ein Erstellungsskript für die Datenbank!

- Anpassung des Skripts auf die gewünschte CCSID
- Abfahren des Skripts.
- Erstellung eines insert select skripts für alle Tables (kann man generieren)
- abfahren des Skripts

et voila!

D*B

[Witaseck]

Das liest sich gut.

Dann kann die CL-Schleife anstatt CPYF einen SQL als "insert into newschema.tablename select * from oldschema.tablename" mit den SQL-Namen der Tabellen ausführen.

[BenderD]

Das liest sich gut.

Dann kann die CL-Schleife anstatt CPYF einen SQL als "insert into newschema.tablename select * from oldschema.tablename" mit den SQL-Namen der Tabellen ausführen.

... ich würde da ein reines SQL skript vorziehen. Du musst Dir natürlich noch ein paar Gedanken mit Deinen constraints machen. Bei referential constraints Reihenfolge der Füll Operationen.
Für eine SQL Datenbank sollte man dazu in der Lage sein, diese mit SQL komplett neu aufzubauen, das sollte mit geringen Anpassungen auf jeder beliebigen SQL Datenbank laufen.

D*B

[B.Hauser]

Wenn Ihr das ganze so macht wie ich es beschrieben habe, braucht Ihr Euch weder um irgendwelche Kopierereien, noch um irgendwelche abhängigen Objekte zu kümmern!

1. SQL Skripte für die Tabellen generieren (wichtig CREATE OR REPLACE)
2. CCSID austauschen
3. Laufen lassen
4. FERTIG!!!