Das kann man doch aber so gar nicht brauchen.

Mein Fall. Im Lager gibt es Kisten.

User 1 legt die Kiste 1 an. Wir halten diese gesperrt und zwar tatsächlich. Also mit Commit-Steuerung WRITE auf Datei ohne COMMIT. Somit gesperrt.

User 2 legt die Kiste 2 an. Jetzt werden verschiedene Dinge gemacht unter anderem wird aus der Kiste 2 die Kiste 3. Alle Datensätze von Kiste 2 gelöscht.

Mache ich jetzt einen READPE mit Kiste 2 (ID 2) um die Sätze zu löschen hauts mir das Programm weg, weil er irgendwann die Kiste 1 lesen will und diese aber von User 1 noch gesperrt ist. Die hat aber überhaupt nix mit dem User 2 zu tun. Und deshalb bleibt mir hier nur die Möglichkeit den READPE mit (N) auf die ID 2 zu machen. Findet er mache ich einen CHAIN und lösche den Satz. Das müsste ich nicht machen, wenn er nicht intern versuchen würde die ID1 zu sperren, die er gar nicht lesen soll. Ganz so einfach ist es nicht sonst könnte ich ja in einer Schleife mit ID immer einen CHAIN machen bis alles gelöscht ist, aber da kommen noch ein paar Bedingungen dazu.

Das hat meiner Meinung nach nichts mit dem herkömmlichen Sperren, UF oder IF oder COMMIT zu tun. Das Problem ist das E hinter READ. Er findet noch einen Satz den er gar nicht zu finden hätte aber finden muss ob er noch im "E"-Bereich ist und anstatt erst zu prüfen und dann zu sperren, versucht erst zu sperren und da hauts ihn weg.