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.
Bei mir sind es "normale" Selects - meistens auf
DB-Views und manchmal auch mit speziellen 'generierten' Spalten (z.B.
CONVERT( MONEY, [Spalte] ) AS [Spalte])
Selbst wenn keine echten Änderungen vorliegen kann es solche Situationen geben, die manchmal kaum nachvollziehbar sind.
Das scheint bei mir der Fall zu sein...
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.
Der Netzwerkverkehr ist nicht das Problem.
Aber: wenn ich ChachedUpdates deaktiviere, kann ich gar nicht mehr (einfach) sehen, wenn es (noch nicht per "Commit" bestätigte) Änderungen in den Queries ggü. der Datenbank gibt - und schon gar nicht,
was genau geändert ist (das versuche ich nämlich auch noch optisch darzustellen - über TField-Vergleiche).
Um das ohne CachedUpdates hinzubekommen, müsste ich mir dann den ursprünglichen Dateninhalt merken (eigene ReadOnly-DataSet?) und mit den aktuellen Daten vergleichen...
Das ist irgendwie auch keine Lösung
Ich versuche jetzt mal, das durch Eure Kommentare gelernte (oder herausgefundene) umzusetzen und schaue mal, ob ich eine vernünftige Erkennung von Änderungen hinbekomme...
...weitere Anmerkungen / "Stupser"
sind gern gesehen!