Originariamente inviato da franzauker
Dipende dalle necessità, mi sembrava di averlo specificato
Tu hai detto che "non ti sembrava una gran soluzione", senza fare distinzioni, altrimenti non ci sarebbe stato alcun problema.


Originariamente inviato da franzauker
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
Come segnalato il modo "furbo" è quello di specificare quali record sono stati aggiornati, e regolarsi di conseguenza
Il traffico è generato dai dati aggiornati che transitano, non dai messaggi UDP usati come notifica.

Originariamente inviato da franzauker
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.
Senza aggiungere un meccanismo di notifica, questo lo fanno normalmente i componenti Delphi al momento dell'invio dei dati (è la "riconciliazione").

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.

Originariamente inviato da franzauker
Su questo punto, come accennato, non sono d'accordo
Neppure su questo, ovviamente occorre porre attenzione a cosa aggiornare, e cosa no
In realtà sono una 50ina di righe in tutto.
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.

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.


Originariamente inviato da franzauker
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.
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.

La tua soluzione ha un altro scopo: garantire che in qualsiasi momento sul client ci siano sempre i dati più aggiornati possibile, che non è gestire la concorrenza.

Infatti, tenuto conto che un PC potrebbe disconnettersi e non ricevere il messaggio, oppure che il messaggio potrebbe arrivare corrotto, il client non saprebbe come aggiornare i propri dati; 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.


Originariamente inviato da franzauker
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.
Sono tutte "innovazioni" al meccanismo che hai ideato per cercare il più possibile di aggiornare i dati sui client, ma sono un "di più".

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, la proporrei anche io, ma sempre avvertendo sui possibili problemi legati a questa metodologia e accertandomi che sia realmente necessaria.


Originariamente inviato da franzauker
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"
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.


Originariamente inviato da franzauker
PS i miei sono solo suggerimenti, ognuno faccia come crede
Questo è implicito: se io voglio assumere una persona che stia al telefono e prema un pulsante ogni volta che c'è un nuovo dato da scaricare, si tratta di una mia libera scelta.

Ma siccome siamo in un forum di discussione, è altrettanto normale discutere le proposte tecniche evidenziando quelli che potrebbero essere problemi o migliorie, a discrezione di ciascuno, anche sbagliando ovviamente (il forum è fatto apposta).


Originariamente inviato da franzauker
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".
Si parlava di "altri user" e "altre postazioni", quindi l'assunzione è giusta.

Ciao!