SQL-Anweisung UPDATE auf CLOB-Spalte mit einer Zeichenfolge >32K

[Joshua]

Ich werde sehen, was mein SW-Provider dazu sagt.

[Fuerchau]

Das kannst du natürlich nicht in einen Command packen.
Aber als Parameter per CreateParameter und dem Typ adLongVarChar bzw. per Unicode mit adLongVarWChar. Als "Size" kannst du gerne 100MB angeben.
Dann sollte ein "Insert into myfile (CLOBName) values(?)" funktionieren.
Binär (BLOB) per adLongVarBinary müsste ebenso klappen.

[Joshua]

Leider hat der SW-Provider Bedenken, dass in einer Multi-Thread-Umgebung andere Prozesse auf die IFS-Datei zugreifen bevor der SQL-UPDATE abgeschlossen ist. Habt Ihr dazu Anregungen?
Vielen Dank
Joshua

[Fuerchau]

Ich habe schon vor Jahren Bilder (jpg, wmf, bmp, ...) in einem BLOB per ODBC auf die AS/400 geschaufelt und wieder heruntergeladen.
Wieso stellt sich das dann für XML-Strings als Problem dar?
Ich habe einfach ein Command-Objekt erstellt:
"insert into mytyble (f1, f2, f3) values(?, ?, ?)"
Der 1. Zugriff auf die Parameter führt bei der AS/400-Verbindung automatisch zur korrekten Definition der Parameter. Die Bilddatei habe ich in ein ByteArray geladen und das Array dann einfach dem richtigen Parameter zugewiesen. Der Execute hat die Daten dann auf die AS/400 geschoben.
Auch mit Bildern vom mehreren 100KB funktionieren hier einwandfrei seit Windows XP und V5.
Für CLOB's statt BLOB's ändert sich bei ADODB nichts, da nehme ich halt Strings statt Byte().

[Joshua]

Bei Verwendung des ODBC-Treibers im .NET-Umfeld kommt die Meldung, dass der Befehl zu lang ist.
UPDATE Tabelle SET Var = longvarchar('

[Fuerchau]

Das liegt aber daran, dass du die Daten nicht als Parametermarker definierst.
Der Fehler bezieht sich ja auf Zeichenfolgekonstante!
Schreibe ein Command-Objekt

update table set var = ? where ...

Für jedes "?" wird ein Parameter per CreateParameter-Methode mit der entsprechenden Ausprägung (z.B. String 2^30) angelegt. Dann können auch Daten die länger als 32KB sind bearbeitet werden.

Ein SQL-Befehl kann 32KB nicht überschreiten, das hat aber mit den Daten selber nichts zu tun.
Auch und gerade bei ODBC sollte man mit Parametermarkern und Parametern arbeiten, das ist erheblich performanter und auch Typsicherer. Ich benötige keine Konvertierung (Dezimal->String) und keine Hochkommatadoppelung.