Clob to Blob

[dschroeder]

Hallo,

vielleicht hat jemand auf die Schnelle eine gute Idee: Wir haben eine Tabelle, in der sich ein Clob-Feld befindet. Das möchten wir zur Weiterverarbeitung in eine andere Tabelle übertragen. In der Zieltabelle ist der Feldtyp allerdings Blob.

Wenn wir das mit SQL machen (...insert into ... select blob(clobfeld) ...) kommt das zwar in der Zieltabelle an, aber der Text ist nicht mehr erkennbar. Es steht scheinbar nur noch Murks in dem Feld.

Ich nehme an, dass das irgendetwas mit der CCSID zu tun hat. Mangels einer besseren Lösung werden wir jetzt versuchen, das Clob als Textdatei im IFS zu speichern und dann das IFS-File in die Blob-Tabelle zu schieben.

Vielleicht kennt ja jemand einen besseren Weg.

Dieter

[B.Hauser]

Hast Du es schon mal ohne explizite Konvertierung versucht?
Wahrscheinlich bringt es nichts, aber ausschließen kann man es nicht.

Birgitta

[Fuerchau]

Woher willst du wissen, dass in dem BLOB murks drinsteht?
Dem ist nämlich nicht so.
Dein Problem beim Auslesen des BLOB's ist die fehlenden Codewandlung.
Die Daten sind nämlich durch das CLOB in EBCDIC (ggf. 273 Deutsch) kodiert.
Gibst du die Daten nun z.B. ins IFS aus mit einer CCSID 1252 o.ä., erfolgt nun keine Codewandlung des BLOB's. Das selbe gilt auch für ODBC/JDBC-Zugriffe (z.B. der 5250-Filetransfer verwendet auch SQL).

Mit Nativemethoden der AS/400 (CPYTOIMPF o.ä.) kannst du leider keine Konvertierung für BLOB erzwingen.

Wenn allerdings dein Ziel sowieso ANSI oder UTF8 ist, kannst du beim Insert in den BLOB dein CLOB in eine ANSI/UTF-CCSID casten:
blob(clob(myclob, newsize, 1208))
für UTF8 sollte funktionieren. Wenn du was anderes haben willst, musst du halt diverses ausprobieren.
Leider kann man ANSI nicht native als SBCS in der Datenbank speicher und ein CLOB ist eben nicht DBCS.
Alternativ geht ggf BLOB(NCLOB(CLOB)), dann sind die Daten in UTF-16 gespeichert. Die weiterverarbeitung gestaltet sich bei Binärdaten halt immer als schwierig.

[dschroeder]

Hast Du es schon mal ohne explizite Konvertierung versucht?
Wahrscheinlich bringt es nichts, aber ausschließen kann man es nicht.

Birgitta

Ohne Konvertierung geht es gar nicht.

[dschroeder]

Woher willst du wissen, dass in dem BLOB murks drinsteht?
Dem ist nämlich nicht so.
Dein Problem beim Auslesen des BLOB's ist die fehlenden Codewandlung.
Die Daten sind nämlich durch das CLOB in EBCDIC (ggf. 273 Deutsch) kodiert.
Gibst du die Daten nun z.B. ins IFS aus mit einer CCSID 1252 o.ä., erfolgt nun keine Codewandlung des BLOB's. Das selbe gilt auch für ODBC/JDBC-Zugriffe (z.B. der 5250-Filetransfer verwendet auch SQL).

Mit Nativemethoden der AS/400 (CPYTOIMPF o.ä.) kannst du leider keine Konvertierung für BLOB erzwingen.

Wenn allerdings dein Ziel sowieso ANSI oder UTF8 ist, kannst du beim Insert in den BLOB dein CLOB in eine ANSI/UTF-CCSID casten:
blob(clob(myclob, newsize, 1208))
für UTF8 sollte funktionieren. Wenn du was anderes haben willst, musst du halt diverses ausprobieren.
Leider kann man ANSI nicht native als SBCS in der Datenbank speicher und ein CLOB ist eben nicht DBCS.
Alternativ geht ggf BLOB(NCLOB(CLOB)), dann sind die Daten in UTF-16 gespeichert. Die weiterverarbeitung gestaltet sich bei Binärdaten halt immer als schwierig.

Danke für die ausführliche Antwort. Wir werden das mal mit der 1208er-Umwandlung ausprobieren. Auf die Idee "clob(clob)" auszuführen, bin ich noch nicht gekommen!
Vielen Dank.

[Fuerchau]

Wie werden denn die Daten aus dem BLOB anschließend tatsächlich verarbeitet?

[dschroeder]

Ein PC-Programm (Java und VBA) holt sich das Blob (darin befindet sich HTML-Text) und fügt den Text in ein Word-Dokument ein.

Mit unserer interaktiven SQL-Oberfläche (wir nutzen dbVisualizer) haben ich deinen Vorschlag mal ausprobiert: select blob(clob(et_htmltxt, 1000, 1208)) from bvsveitx;
Wenn ich das so auslese, kann der dbVisualizer den Text anzeigen. Es scheint also zu funktionieren. Es sieht auch so aus, als würde die Längenangabe (hier 1000) nicht exakt benötgt. Solange der Wert ausreichend groß ist, scheint es zu klappen. Nach der Umwandlung auf UTF-8 scheint die korrekte Länge (in unserem Beispiel weniger als 1000) verwendet zu werden.

Wir müssen das aber erst noch in die Programme einbauen, um es genau zu verifizieren. Wenn das klappt, war das eine super Idee von dir. Nochmals danke.

[Fuerchau]

Warum könnt ihr dann die "Arbeitstabelle" nicht einfach als CLOB umstellen?
Bzw. warum überhaupt LOB?
Können denn Daten von mehr als 16KB vorkommen?
Da würde ggf. ein NVARCHAR(16000) ausreichen.

[dschroeder]

Die Arbeitstabelle ist "allgemeingültig". Da stehen auch andere Dinge drin, die weiterverarbeitet werden (z.B. PDFs, Grafiken, Word-Dokumente usw.). Jetzt muss neuerdings auch ein HTML-Text, der als CLOB vorliegt, da rein. Der HTML-Text kann wesentlich größer als 16KB sein. Der Text wird vom TinyMCE Editor erzeugt und kann ca. 1 MB groß sein.

[dschroeder]

Ach, übrigens: Du hattest ja oben weiter den Vorschlag BLOB(NCLOB(CLOB)) ins Spiel gebracht. Die Funktion NCLOB habe ich noch nie gehört. Es scheint sie auf der iSeries auch nicht zu geben. Aber mein dbVisualizer scheint "nclob" als Schlüsselwort zu kennen.

[Fuerchau]

Ab V7 gibt es die N(ational) Felder:
NCHAR, NVARCHAR, NCLOB, ...

Und für HTML bietet sich ja UTF-8 an, die Zielanwendung muss das allerdingsg auch wissen, damit die Daten nicht als ANSI interpretiert werden.

[dschroeder]

Danke. Im SQL-Handbuch tauchen die Begriffe nicht unter den skalaren Funktionen auf. Aber man findet sie im Bereich der CAST Anweisung. Mir ist trotzdem noch nicht ganz klar, was man damit macht. Ändert man damit einen (beliebigen) Text in die nationale Zeichensatzcodierung?