@Fuerchau. Ich brauche jetzt zum Verständnis nochmal ein abnicken.

Gehen wir von Aufträgen und Auftragspositionen aus

In den nachfolgenden Fällen wurde vorher ein STRCMTCTL gemacht


Beim normalen READ/CHAIN und UPDATE

Wenn ich Auftrag 1 mit Position 1 und 2 geschrieben habe, habe ich auf diese Sätze eine Sperre solange bis ich den COMMIT oder ROLBK ausführe.

Ein ganz anderes Programm (oder aber auch das selbe Programm von einer anderen Sitzung aus aufgerufen) was auch unter commit läuft kann dann problemos auf Auftrag 2 zugreifen und dort was ändern. Hält natürlich dort die Sperren auch bis ein COMMIT oder ROLBK erfolgt.

Wenn ich das jetzt richtig verstanden habe verhält es sich aber bei SQL anders
Wenn also Programm 1 jetzt mit SQL SELECT, UPDATE arbeiten würde und ich hätte einen UPDATE auf einen oder mehrere Sätze des Auftrags 1 gemacht ohne einen COMMIT auszuführen. Dann könnte ein anderes Programm (oder eben wieder dieses von einer anderen Sitzung aus) gar nicht auf die Datei via SQL zugreifen und/oder keine UPDATES machen. Egal ob dieses dann den UPDATE auf Auftrag 2 machen wollte?

Habe ich das richtig verstanden?

Das heißt im Falle von SQL habe ich den Vorteil dass ich keine konkurierenden Locks erzeugen kann, dafür aber wahrscheinlich etwas länger warten muss bis die Datei wieder frei ist?

Viele Grüße Harald