Transaktion in einer SQL UDF durchführen

[Fuerchau]

Ein Select ist eine Massenoperation und muss optimiert werden. Deshalb müssen UDF's so einfach wie irgend möglich gestaltet werden.
Du kannst ja nicht verhindern, wo die UDF denn verwendet wird.
Ggf. fällt jemandem ein, dies in der Where-Klausel zu tun und dann kann im Zweifel ein Tablescan passieren statt eines Indexscans.

Schau dir das Transaktionsszenario an:
*CHG liest Daten die Committed sind.
Wenn du also bei einem Select, der 1000de und Millionen von Zeilen liest, eine UDF mit Commit verwendest stellst du den Optimizer vor gewaltige Probleme. Auch andere parallele Zugriffe aus anderen Verbindungen/Jobs werden ggf. Konsistenzprobleme bekommen.

Eine Transaktion in einer DB stellt grundsätzlich kein Problem dar.
Wenn sie denn via Businesslogik vom Client der DB initiiert und kontrolliert wird.
Denn wenn mir irgend eine UDF da dazwischen funkt, kann ich meiner Transaktion nicht mehr sicher sein und auf einen Rollback keinen konsistenten Zustand bekommen.

Ein Commit schreibt geänderte Daten fest!

[dschroeder]

Eine Transaktion in einer DB stellt grundsätzlich kein Problem dar.
Wenn sie denn via Businesslogik vom Client der DB initiiert und kontrolliert wird.
Denn wenn mir irgend eine UDF da dazwischen funkt, kann ich meiner Transaktion nicht mehr sicher sein und auf einen Rollback keinen konsistenten Zustand bekommen.

Ein Commit schreibt geänderte Daten fest!

Langsam wird mit die Problematik mehr und mehr bewusst. In meinem Fall weiß ich natürlich, dass die UDF nur für einen ganz bestimmten Zweck verwendet wird. Aber mir ist dank eurer Erklärungen jetzt klarer, dass man nicht einfach so zwischendurch Transaktionen einstreuen kann.

Ich würde meine Problem am liebsten alle mit RPG lösen. Aber bei Blobs ist RPG ja sehr stark größenbeschränkt. Da erscheint mir SQL als das naheliegende Werkzeug.