La domanda posta, ossia questa
il problema e' sempre lo stesso:
se USER1 aggiunge/modifica/cancella un record... tale modifica verra' vista USER2 solo nel momento in cui USER2 effettua close e open della tabella.
io l'ho interpretata "come fare in modo che l'USER2 veda le modifiche SUBITO, anzichè quando fa un close/open?


Tu hai detto che "non ti sembrava una gran soluzione", senza fare distinzioni, altrimenti non ci sarebbe stato alcun problema.
Confermo che non è una gran soluzione quello di usare una tabella e scriverci sopra le ultime "viste"

avevo pensato cosi:
creo una tabella nel database:
codice:
CREATE TABLE TabellaUltimoAggiornamento(
ID INTEGER NOT NULL PRIMARY KEY,
NomeTabella VARCHAR(100),
UltimoAgg varchar(16)); /* yyyymmddhhmmss */


aggiornando il record relativo alla tabella modificata ogni volta che che viene effettuato un insert/update/delete nella medesima tabella.
Continua a non sembrarmi una gran soluzione
Il traffico è generato dai dati aggiornati che transitano, non dai messaggi UDP usati come notifica.
Se vuoi i dati aggiornati (che sono il requisito di progetto) -> li devi fetchare -> devi avere il traffico.
Non è che ci siano alternative
Senza aggiungere un meccanismo di notifica, questo lo fanno normalmente i componenti Delphi al momento dell'invio dei dati (è la "riconciliazione").
??? Sono un pochino perplesso, magari parli di un meccanismo che non conosco

I casi frequenti che tu indichi, in realtà, sono casi specifici della tua applicazione, che ha requisiti particolari e che, giustamente (ci mancherebbe) hai risolto nel modo che hai descritto.
Bhè diciamo che la richiesta di avere il refresh dei dati il prima possibile è comune tra tutti i clienti.
Non ne ho ancora trovato uno che mi abbia chiesto il contrario, bisogna però precisare che i "miei clienti" non sono "tutti i clienti del mondo"

Le performance diminuiscono senz'altro, visto che - oltre alla normale gestione dei dati che rimane - l'applicazione deve ricevere messaggi di aggiornamento e scaricarsi in automatico pacchetti di dati che, in un meccanismo di "riconciliazione" normale (quello incorporato nel componente ClientDataSet, ad esempio) non sarebbe necessario, e questo lo si nota molto di più se si esce da una rete locale e si approda a Internet.
Continuo a non essere particolarmente d'accordo, per la semplice considerazione che se i client devono avere i dati, da qualche parte li devono fetchare (client intesi come macchine distinte).

E, in qualsiasi modo scegli, li devi comunque far arrivare
Il punto, come dicevo, è dato dal fatto che la tua applicazione gestisce una casistica che necessariamente, come prerequisito, richiede di dover fare questa operazione per risolvere specifiche esigenze del cliente, quindi l'operazione è necessaria e la questione del tempo aggiuntivo introdotto per gestire i messaggi sulla rete è ben bilanciata dalla risoluzione di specifici problemi, quindi è accettabile.
In realtà, come accennato, il "refresh immediato" può essere esteso a 1, alcune o tutte le tabelle.

Sta alla scelta (ed esperienza) del progettista trovare il "giusto" bilanciamento.
La mia obiezione infatti è questa: l'introduzione del meccanismo che hai descritto e le istruzioni annesse NON sono necessarie per gestire la concorrenza, poiché questa è già gestita dai componenti standard di Delphi.
Concorrenza intesa con la domanda posta, ossia "refresh"
Infatti, tenuto conto che un PC potrebbe disconnettersi e non ricevere il messaggio,
Se è disconnesso dalla rete -> lo sarà anche dal server SQL (non trattiamo le connessioni stateful, che non mi paiono corrispondenti al profilo della domanda)
oppure che il messaggio potrebbe arrivare corrotto,
Su una LAN è sostanzialmente impossibile, (tralascio i vari componentini con CRC nei messaggi etc)
il client non saprebbe come aggiornare i propri dati;
Certo, e non fa nulla
detto questo, la tua soluzione NON è sufficiente a garantire la gestione corretta della concorrenza, e infatti risolve un altro problema, cioè quello di aumentare la probabilità che il client possieda già - per comodità dell'utente - i dati più aggiornati possibili.
In realtà si possono mettere facilmente in piedi meccanismi simili al 3way handshaking, ossia messaggi "di ritorno".
Ma, nella mia esperienza, su LAN mai e poi mai ho avuto questi problemi


Intendiamoci, per lo scopo da ottenere, la tua soluzione è senz'altro pulita e conservatrice, e se qualcuno chiedesse come cercare di mantenere aggiornato i dati di un client...
Evidentemente avevo capito male la domanda posta (anche se non mi pare)

...Se l'aggiornamento si basa solo su questo, basterebbe aggiungere un nuovo cliente e toglierne uno vecchio per far sì che il client non riceva l'aggiornamento, visto che il totale rimane sempre lo stesso.
Normalmente i clienti non si cancellano mai (anzi, diciamo mai) per non de-normalizzare gli archivi.
Si flaggano "obsoleti" (al più).
In questo caso il problema è davvero la count(*) [mi riferisco a mysql].
In certi casi i clienti sono 400.000, e contarli è devastante

Comunque ho solo provato a dare qualche suggerimento, non mi intendo molto di queste cose.

Ciao!