CachedUpdates sorgt dafür, dass Änderungen nicht sofort an die Datenbank geschickt werden. Deswegen kann man über UpdatesPending prüfen, ob noch was im Cache ist. D.h. man hat zwar lokal (in der Anwendung) Änderungen, aber die stehen noch nicht in der
DB. Dafür sorgt dann ApplyUpdates. Bei einem Programmabsturz sind deine lokalen Änderungen dann nicht in der
DB. Der Vorteil von CachedUpdates ist der geringere Netzwerkverkehr. Liegt die
DB lokal auf dem Anwendungsrechner, bringt CachedUpdates nicht mehr viel.
Schaltet man CacheUpdates aus, müsste UpdatesPending immer False liefern.
Zum Problem:
Du verwendest Queries, wenn ich es richtig gesehen habe. Diese können eigene DML-Anweisungen (Edit, Delete, Insert) haben, die unter Umständen automatisch ausgelöst werden. Selbst wenn keine echten Änderungen vorliegen kann es solche Situationen geben, die manchmal kaum nachvollziehbar sind. Damit meine ich Änderungen, die zwar von der Komponente registriert werden, aber die Inhalte trotzdem unverändert sind. Ein Update ohne inhaltliche Änderungen ist immer noch ein Update. Unter Umständen kann es dann sogar passieren, dass ein ApplyUpdates zu einem Fehler führt.
Die Ursachen können vielfältig und teilweise kaum zu erklären sein. Ich denke aber, dass es nichts mit der
BDE zu tun haben wird. Irgendein Event kann bei einem Vergleich zu einem ungewollten Update führen. Eine Formatierung für ein Edit-Feld führt scheinbar zu einer Änderung. Komplexe Master-Detail-Abhängigkeiten können bei manueller Steuerung auch dazu führen. Eine ungewolltes oder unkontrolliertes Edit/Post kann ein LiveUpdate auslösen und dadurch ein UpdatesPending auf True setzen. Ich meine auch mal gelesen zu haben, dass bestimmte Prefixe bei Feldnamen zu so einem Problem geführt haben sollen.
Da du sowieso mit Transaktionen arbeitest, würde ich CachedUpdates deaktivieren. Wenn du nicht gerade Massenänderungen machst, ist der Netzwerkverkehr zu vernachlässigen und in dem Fall könntest du CachedUpdates auch gezielt aktivieren.