Clob to Blob

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

[Fuerchau]

Die Begrifflichkeit ist hier unglücklich gewählt.
N(ational) Character heißt nichts weiter, dass nun multinationale Zeichen verwendet werden dürfen. Man hätte ja auch MNCHAR verwenden können.
Historie auf der AS/400:
GRAPHIC(nn) CCSID 13488 => UCS2 => RPG-Typ "C".
NCHAR(nn) => CCSID 1200 => UTF-16 => RPG-Typ "C"

(nn) ist hier die Anzahl Zeichen und nicht Bytes, also für den Platz mal 2 zu nehmen!

Die Unterscheidung ist im Wesentlichen, dass UCS2 auf 2-Byte-Zeichen beschränkt ist.
UTF-16 ist ein variabler 2/4-Byte-Zeichensatz und kann somit alle gültigen und zukünftigen Zeichen aufnehmen. UTF-16 ist allerdings in der CLientwelt weniger verbreitet. Da findet UTF-8 eher Anwendung, das ist eine 1-4-Byte-Zeichensatz, also variabel von 1 bis 4 möglichen Zeichen.

Die Oracle-DB arbeitet bei NCHAR z.B. mit UTF-8, was bei der Anlage von Tabellen allerdings zu beachten ist. Wählt man z.B. NCHAR(1) so sind damit nicht 1 Zeichen sondern 1 Byte gemeint. Spätestens bei deutschen Umlauten und sonstigen europäischen Sonderzeichen kann man da nichts mehr unterbringen.
Ich hatte da mal ein kleines Übertragungsproblem in eine Oracle-DB mit NCHAR(2). Hier sollte der Wert "ÜA" untergebracht werden. in UTF-8 sind das aber 3 Bytes und die Oracle-DB hat das abgelehnt.
Aber das ist hier "Off-Topic".

[dschroeder]

Vielen Dank für deine Erklärung!

[dschroeder]

So, wir haben das ganze jetzt im Einsatz. Mit der Idee, die clob-Funktion nochmal auf ein Clob-Feld anzuwenden, um den gewünschten Zeichensatz zu bekommen, klappt wunderbar. Unsere per TinyMCE editierten Texte landen wunderschön formatiert im Microsoft Word.

Nochmals vielen Dank!