Das widerspricht jetzt völlig meinem Verständnis.
Dann empfehle ich die Studie der einschlägigen Lektüre. Obwohl nicht mehr ganz so einfach zu finden, steht in der Hilfe doch so einiges zum Thema
Cached Updates drin:
https://docwiki.embarcadero.com/Libr....CachedUpdates
Wohin wird das denn durch "Post" gespeichert?
Wie in der Doku erwähnt, in einen lokalen Speicherbereich, der im Format einer
Paradox-Table entspricht.
Bei der ersten Änderung des Master- oder eines der Detail-Datensätze starte ich auf der Datenbank eine Transaktion - dann können soviel Änderungen durchgeführt werden wie gewünscht.
Und erst wenn alle Änderungen entweder gespeichert (Commit) oder verworfen (Rollback) werden, sind die Änderungen weg.
Bei
CachedUpdates ist die Transaktions-Steuerung gar nicht involviert. Das findet ausschließlich im DataSet (TQuery) statt. Erst beim Aufruf von
ApplyUpdates wird die Datenbank involviert und die Transaktion bekommt die Daten. Wenn du bereits vorher eine Transaktion gestartet hast, dann hat das lediglich Einfluss darauf, welche Änderungen von anderen Clients du sehen kannst. Deine eigenen Änderungen sind vor dem
ApplyUpdates gar nicht in der Datenbank vorhanden.
Und bis dahin muss ich doch programmtechnisch feststellen können, ob sich im Master-Datensatz oder
einem der Detail-Datensätze Änderungen (d.h. es sind Daten im
Query ggü. dem Datenbankinhalt verändert) befinden.
Und da möchte ich eben verstehen, mit welchen Properties / Aufrufen etc. auf den TQuery / TDataSet (oder auch sonst irgendwie) ich das einfachst möglich - aber korrekt - feststellen kann...
Wenn der aktuelle Datensatz im Insert/Edit Mode ist, dann gibt
Modified an ob dieser geändert wurde (gegebenenfalls erst nach Aufruf von
UpdateRecord). Ergänzend dazu gibt
UpdatesPending an, ob es bereits andere Änderungen an den Daten der
Query seit dem letzten
ApplyUpdates gegeben hat, die aber noch nicht an die Datenbank übertragen wurden.