.Dein Test mit ReadCommitted bringt genau das Ergebnis, dass eine solche Transaktion bringen darf!
Die Aussage ist ja bei dieser Aktion, dass alle Daten, die während des Lesens committed sind, also auch die, die committed werden nach dem der Select gestartet ist, sichtbar werden.
Nun liegt es in der Tatsache begründet, dass der Cursor über einen Teil der Daten schon hinweg ist und wenn der Commit dann zuschlägt, ab diesem Zeitpunkt die restlichen Daten nun sichtbar werden.
Dies passiert auch z.B. bei der DB2, die ich testen kann. Hier gibts keine Satzversionen oder Transaktionsmarker, daher werden alle Daten, die während der Aktion geändert oder hinzugefügt wurden, gesperrt. Gelöschte Sätze sind tatsächlich auch weg.
Eine andere Connection überliest halt die gesperrten Zeilen. Sobald aber die 1. Transaktion die Sperre aufhebt, kann die lesende Transaktion nun diese Daten mitlesen.
Bei der Oracle-DB ist das i.Ü. genauso, ebenso der SQL-Server:
https://learn.microsoft.com/en-us/sql/t ... rver-ver16
Siehe ab "READ COMMITTED".
Die Firebird verhält sich also genau so, wie sie sich bei ReadCommittted verhalten muss.
Da nun auch bei unserem Konzept und bei größeren Web-Installationen nun ab und zu seltsame Ergebnisse ergeben, muss ich bzgl. der Dashboards tatsächlich zur Sicherheit auf Snapshot umstellen. Denn leider hat es sich im Ablauf ergeben, dass auch tagsüber willkürlich verteilt ETL-Prozesse laufen. Diese fassen zwar Delete/Insert in eine Transaktion und per Definition dürfen 2 ETL's in dieselbe Tabelle nicht laufen, aber beim Web weiß man halt nie, welcher User gerade diese Daten für sein Dashboard abfragt. Somit wird vermutlich da ebenso der Effekt auftreten, dass die Daten in sich nicht konsistent sind.
Fazit:
Die FB vehält sich per Definition bei ReadCommitted korrekt, da eben sog. Phantom-Reads zulässig sind. Daher braucht da nichts geändert oder automatisch umgestellt werden.
Und ich muss für meine Dashboards eben auf Snapshot umstellen.
