Transaktion in einer SQL UDF durchführen

[Fuerchau]

Nun, IWS ist ja schon seeeehr alt. Da frage ich mich, ob dies noch zeitgemäß ist.

Aber zurück zur Eingangsfrage:
Was soll denn die UDF schreiben was mit RPGLE nicht geht?
Wie steht das im Zusammenhang mit IWS und dem Aufruf?

Da du die Dokumente > 8MB nicht in RPGLE verarbeiten willst, kann IWS diese doch native mit SQL holen?
Wie gesagt, Dokumente IFS => DB und DB => IFS geht mit oben genannten Methoden.
Wenn ein Dokument nun per IWS an einen Client gesendet werden soll, kann das nicht auch eine Datei aus dem IFS sein die man da vorher hingestellt hat?

Zumal LOB's auch immerhin nur max. 2GB groß sein können, reicht das denn?

Überschreiben von LOB bis 16M in RPGLE:

d ds static
d FileString SQLTYPE(DBCLOB:8000000) ccsid(1200)
d FileData c len(8000000) overlay(FILESTRING_DATA)

[dschroeder]

Du hast es exakt beschrieben: Mit RPG und embedded SQL kann ich die Daten (max 2 GB) in eine DB schreiben. Aber dann brauche ich wieder SQL, um Daten per Webservice auszuliefern. Beim IWS kann man ein SQL-Statement angeben, um die Daten auszuliefern.

Zum Schreiben das Gleiche, nur umgekehrt:
Der Webservice Client (eine Java-Anwendung) liefert mir ein großes BLOB, z.B. 20 MB groß, also zu groß für RPG. (Um genau zu sein: Ich bekomme nicht direkt ein BLOB, sondern ein Json-Clob, in dem das Blob base64 codiert enthalten ist. Aber das spielt hier keine Rolle, denke ich)

Das große Clob kann ich im RPG nicht empfangen. Also hänge ich an den IWS kein RPG Programm, sondern eine SQL-Funktion, die das als Clob 2GB empfangen kann. Was soll ich jetzt mit dem Clob weiter machen? Auch die SQL Funktion kann das nicht an RPG weitergeben. Ich könnte es natürlich in eine DB schreiben oder ins IFS schreiben und dann ein RPG Programm aufrufen, das das ganze häppchenweise weiterverarbeitet.

Da finde ich es einfacher, es direkt mit SQL in die Tabelle zu schreiben, wo es hingehört. Zu dem Blob gehören dann noch ein paar Metadaten (z.B. mimeType), die in einer anderen Tabelle gespeichert werden müssen. Da die Speicherung des Blobs also 2 Tabellen erfordert, hätte ich eine Transaktion hier ganz hübsch gefunden.