..
Also vor der Aktualisierung des Grids einfach eine
Query.Connection.BeginTransaction
danach
Query.Connection.Commit.
Query.Connection könnte auch
Query.DataBase bei ZEOS heißen.
Also das scheint mir nicht richtig zu sein.
Transaktionshandling in einem Anzeigeprogramm ändert gar nichts.
Transaktionen sollten -falls sie nicht auf Automatic stehen- von dem Code gesteuert werden, der DML macht.
Die Sichtbarkeit der Daten ist dann so:
Der Client, der in-transaction ist sieht alles was andere commited haben plus seine eigenen "offenen" Transactionsdaten.
Andere Clients sehen davon nichts, egal wieviel Begin-/Endtransactions sie machen.
Spannender wird es natürlich, wenn Anzeige und Änderung in einem Programm erfolgen. Gemäß oben, sollte ein Client, der einfügt/ändert auch "sehen" können, was er da verzapft. Ist auch normalerweise so (bei "automatic"), außer man verwaltet die Transaktionen selbst. Wenn man das verbockt, und Transaktionen offen lässt (natürlich unbeabsichtigt), wird niemand diese Daten sehen. Ausnahme hier ist natürlich, wenn man nun noch zur Krönung des Chaos beginnt, mit den Isolation Leveln zu experimentieren um "seine Transaktionsdaten" irgendwo zu finden.
Mein Tipp für den Anfang:
Transaktion auf Automatisch. Wenn alles flutscht im Testbetrieb, Testbetrieb erweitern auf 2 oder mehr Clients, ggF. mit konkurrierenden Zugriffen, jenachdem was man überhaupt implementieren will.
Wenn das auch alles flutscht, kann man - wenn man es unbedingt ausprobieren will- manuelles Transaktionshandling einbauen. Und wenn man dann noch immer Spaß hat, kann man auch mit isolation levels spielen, wofür auch immer.
Aus gegebenem Anlaß dazu ein kleiner Vergleich:
Isolation Level != commited sind so ähnlich wie Wahlprognosen. Mglw. total spannend, aber am Ende des Tages bedeutungslos.