Originariamente inviato da alka
Il refresh immediato è una cosa differente rispetto a ciò di cui si stava parlando, e al massimo si può aggiungere all'architettura che è stata descritta sino ad ora, ma non è una soluzione sostitutiva, né tanto meno obbligatoria, infatti non mi è mai stata richiesta in alcuna applicazione.
Dipende dalle necessità, mi sembrava di averlo specificato
Inoltre, una simile implementazione va attentamente ponderata, perché in un sistema in cui sono presenti molti utenti la circolazione di simili messaggi può generare un massiccio traffico di rete
Quale "massiccio traffico di rete"?
Anche con un centinaio di utenti i messaggi UDP sono così piccoli (e richiedono così poco per essere gestiti dal sistema) che non c'è alcun rallentamento, o almeno non l'ho mai riscontrato
o andare ad aggiornare informazioni sui client quando questi non ne hanno bisogno, anzi in certi casi può ingenerare problemi quando riguardano dati su cui è in corso un'operazione, oppure che sono già filtrati in qualche modo e così via.
Come segnalato il modo "furbo" è quello di specificare quali record sono stati aggiornati, e regolarsi di conseguenza
Un meccanismo di questo tipo lo valuterei se e solo se esiste una esplicita richiesta di aggiornamento di determinate informazioni in tempo reale (può andare bene per una chat, ad esempio, mentre non mi sembra indispensabile per l'anagrafica dei clienti),
Dipende, soprattutto se quest'ultima contiene dati al suo interno (esempio: sconti).
nel caso di agenti e backoffice che operano sui medesimi clienti "refreshare" le condizioni commerciali dei clienti (immediatamente) è proprio uno dei casi tipici, soprattutto nel caso in cui si stiano facendo degli ordini a fornitore molto grandi (che richiedono decine di minuti).

Oppure (altro caso frequente) l'inserimento separato di un cliente (backoffice) e immediata "visibilità" ai front-office (agente) etc.

visto che può produrre un serio decadimento delle performance,
Su questo punto, come accennato, non sono d'accordo
numerosi "effetti collaterali" nell'applicazione
Neppure su questo, ovviamente occorre porre attenzione a cosa aggiornare, e cosa no
e, in ogni caso, è un meccanismo da implementare a parte (rispetto alla gestione delle riconciliazioni fornita dal ClientDataSet che è quasi totalmente automatica).
In realtà sono una 50ina di righe in tutto.
---
Riguardo poi alla domanda ne vedo 2 nel thread,

1) come e quando aprire i dati
2) come gestire la concorrenza.

Mi pare di aver suggerito due soluzioni per entrambe, non necessariamente le migliori.

Metto anche la terza, ossia lo "screensaver". Più brutalmente si può fare un timer che calcola l'idle time (è banale), e poi "fa qualcosa", tipo pre-caricare i dati, refresharli etc.

In certi casi basta semplicemente un test del tipo "fai una count sulla tabella clienti, verifica se il numero dei record è uguale al recordcount del mio dataset, nel caso aggiorna"

Non è perfetto (qui c'è aggiunta, non modifica), e questa sì che può dare problemi di performances se la count(*) viene fatto su un database che NON ha il supporto per il conteggio delle righe (es. mysql-innodb, mysql-myisam se ci sono WHERE) etc

---
PS i miei sono solo suggerimenti, ognuno faccia come crede

EDIT: mi sono accorto di non aver fatto un'assunzione che però dipende dal contesto.
Spedire messaggi UDP ha senso in un ambiente con più client su più macchine fisicamente diverse, ovviamente.

Ha molto meno senso auto-spedirseli (una singola macchina).

Se il problema è quindi "più finestre dello stesso programma su una certa macchina" oppure "più finestre dello stesso programma su macchine distinte".

Tendo sempre a dar per scontato che i client siano tanti, ma non sempre è così