Ausserdem muss man noch bedenken, dass bei Joins ggf. auf Kopien zugegriffen wird (ALWCPYDTA), gibts auch irgend eine QAQQINI-Einstellung dafür.
Desweiteren wird beim Lesen auch häufig geblockt, so dass bereits mehrere Sätze im Puffer stehen, während andere "lustig" die Daten bereits verändern.

Das hat auch gar nichts mit SQL zu tun, sonder geschieht auch bei (ILE)RPG.
Verarbeite ich eine Datei sequentiell mit Input, kann ich für späteren Update nicht garantieren, dass die Daten noch korrekt sind.

Hierfür gibts das Konzpt der Satzsperren, so dass ich bei einer U-Datei den Satz vor Änderungen schütze.

Bei SQL geht das nur, wenn die Dateien journalisiert werden, da ich dann mit dem entsprechenden Commitlevel bereits beim Lesen sperren kann. Ansonsten erlaubt SQL (wie bei I-Dateien) jederzeit einen "Dirty"-Read !

Um also "alten" Schrott nicht zurückzuschreiben muss man entweder journalisieren, oder (so machts z.B. MS-Access automatisch):

update myfile set field=newval
where myfile.key=mykey and field=oldval

SQLCOD=0 bedeutet, Update erfolgreich, SQLCOD=100 bedeutet
a) Satz nicht mehr da oder
b) Oldval stimmt nicht mehr

Die RRN kann da eher tödlich werden, da diese je nach Methode inzwischen anders sein kann.
Es soll Anwendungen geben, die einen zu verändernden Satz vorher löschen und dann neu anlegen. Die RRN ist daher nie eine Garantie, dass diese hinterher auch wieder stimmt.