SELECT..FOR UPDATE/Embedded SQL

[Fuerchau]

Nein, ein Join kann nicht upgedated werden.
Hier benötigst du einen Single-Select.

[tarkusch]

Oje, danke Vielmals für die rasche Antwort.

[BenderD]

... das gilt mitlerweile auch nicht mehr unumschränkt. Wenn man das als View vernagelt, kann man auf selbige einen instead Trigger erstellen.

D*B

[Fuerchau]

Ja, aber nicht per "update of" mit Satzsperre.
Das ist sowieso nicht SQL-Like. Frameworks generieren meist SQL's wie folgenden:

update mytable
set field = newvalue
where tablekey = key and field = oldvalue ...

Damit wird dann Konsistenz erreicht und ein "zerstörerischer" konkurierender Update verhindert.
Wenn man dann nicht per "select * " alle Felder verarztet können durchaus viele Anwendungen mit verschiedenen Teilen eines Satzes Updates durchführen.

Satzsperren verhindern doch konkurierendes Update?
Dem ist im Transaktionsumfeld mitnichten so.
Die (meisten) Frameworks arbeiten "offline". Es werden alle Informationen in interne Tabellen gelesen, dann werden diverse Änderungen gemacht (Ändern, Löschen, Hinzufügen) und anschließend der gesamte Update in einer Transaktion durchgeführt.
Zwischen Lesen und Update kann also genug Zeit vergehen in der eine Information geändert wurde.
Satzsperren gibt es da nicht.
Bei Fehlern kann man per Filter die fehlerhaften Daten harausbekommen und ggf. Rollback durchführen ansonsten halt Commit. Damit sind Sperren dann alle aufgehoben.
Nun kann man ja sagen, dass ich per Commitdefinition auch beim Lesen sperre, das funktioniert auch ohne Framework. Mit Framework wird die Verbindung aber durchaus getrennt somit sind Lese-Satzsperren nicht möglich.