Also das Problem ist ein Allgemeines, und in der Architektur von Client-Server-Anwendungen begründet.
Blöderweise hilft Dir diese Erkenntnis nicht.
Du kannst versuchen, deine View (also das, was Du im Grid siehst), über einzelne TIBTable und Master-Detail-Verknüpfungen nachzubauen. Wenn Du dann an einer Tabelle etwas änderst, werden diese Änderungen auch in der zusammengeklickten 'View' sichtbar. Blöderweise hebelt man dadurch die Vorteile eines
SQL-Servers aus, nämlich das extrem schnelle Suchen und Bereitstellen von Daten.
Wir haben einen anderen Ansatz verfolgt: Unsere Daten sind in einem TdxMemData, Du kannst aber auch ein TcxCustomDataSource ableiten. Wenn wir jetzt Änderungen an einer der diesen Daten zugrundeliegenden Tabellen posten, ändern wir diese Daten imn TdxMemData (oder TcxCustomDataSource) eben 'von Hand'. Das ist natürlich ziemlich bescheuert, aber anders bekommen wir das nicht hin.
Wir ziehen also die Daten vom Server und wissen ganz genau, wann welcher Record verändert werden muss. Eben weil wir in der Update-Logik die komplette View nachgebaut haben.
Wir haben zudem ein Messaging-System (
TCP), sodaß die Änderungen von anderen Workstations auch auf allen Clients unmittelbar sichtbar werden, ohne das Jemand auf die Refresh-Taste haut.
Wie Du siehst, sind das aber alles Frickellösungen, eine allumfassende Lösung zu diesem Problem gibt es
imho nicht. Denn der Traum, nämlich das die
Query (also die View) glaskugelartig genau die Datensätze neu lädt, die sich verändert haben, ist so nicht realisierbar.
Für einen konkreten, speziellen Fall ist das aber sicherlich möglich.