Hallo Linuchs,
Aus ferner Vergangenheit (Oracle DB) kenne ich, dass ein Satz zum Ändern gelesen wird. Er wird also eine undefiniert lange Zeit „geschützt“ gegen Änderungen / Löschungen durch andere User
Ein Update muss vorher lesen, sonst könntest Du kein "SET col = col+1" oder so machen. Und ein Update hinterlässt einen Write-Lock auf der Row, so dass sie kein anderer mehr schreiben kann.
Aber auch ein SELECT kann einen Lock hinterlassen, einen Read-Lock. Das hängt vom Isolation Level ab und davon, ob eine Transaktion begonnen wird. Ohne Transaktion wird meines Wissens keine Lesesperre gesetzt. Die Isolation ist per Default relativ hoch, man kann das aber auch absenken.
Ein Read-Lock kann vom gleichen Programm zum Write-Lock erhoben werden, aber ein zweites Programm bekommt maximal einen weiteren Read-Lock. Ein Write-Lock kann nur erzeugt werden, wenn es keine Read-Locks gibt. Aber, wie gesagt, die genauen Regeln hängen vom Isolation Level ab.
Die Lesesperre endet mit der Transaktion, also mit einem expliziten COMMIT bzw. ROLLBACK, oder einem impliziten Transaktionsende bei Ende des Programms. Da gibt's viel Konfigurationsspielraum.
Eine Write-Lock verhindert normalerweise auch, dass der Satz von anderen gelesen wird. Es sei denn, sie machen einen "uncommitted read", dann geht's wieder.
Wie das bei Access läuft, ist eine andere Frage und die kann ich nicht beantworten.
Rolf
sumpsi - posui - obstruxi