Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Sincronizzazione tabella su 2 db in remoto

Mi sto arrovellando sul seguente problema senza riuscire a risolvere 
"democraticamente" il problema.
Ho 2 database su 2 pc che comunicano tra loro solo tramite posta 
elettronica.
I 2 database contengono alcune tabelle che vanno sincronizzate, per 
semplificare una tabella clienti.
Ho cercato un algoritmo, ma mi blocco sempre analizzando il caso in cui, 
se su entrambi i PC viene modificato un record, devo dare io, da codice, 
una priorita' all'uno piuttosto che all'altro record modificato.
Avevo pensato di aggiungere un campo di tipo date/time dove memorizzare 
la data/ora della modifica e fare un confronto tra i valori contenuti in 
questo campo, ma sapendo con quale cura le persone aggiornano e 
controllano l'orologio di windows la ho scartata.
Esiste un altro metodo?
grazie
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 Esiste un altro metodo?
se non puoi decidere un master, sembra anche a me la migliore. all'avvio del
tuo programma sincronizzali da codice su un orologio tipo il galileo
ferraris, giusto con uno splash di informazione per gli utenti.
in ogni caso e' meglio che gli utenti sappiano che le loro modifiche possono
andare perse...
eventualmente puoi creare una tabella a struttura identica per buttarci
dentro le schede rimpiazzate, una specie di log.
ciao

 ha scritto nel messaggio
news:b2i9ge$1d1kbt$1...@ID-97197.news.dfncis.de...


 
Livello di informatizzazione -7. Sono quelli di cui avevo gia' parlato 
qui che regolarmente spengono il pc mentre viene effettuata la 
compattazione del db ... :-(


 per esempoio ogni mattina o ogni TOT ore!
Solo uno dei 2 lo e' e comunque non sarebbe un problema la sincronia 
anche per una connessione dial-up: differenze di qualche minuto non sono 
importanti, raramente modificheranno lo stesso record nello stesso 
istante ...
Come dicevo ad a.p. non mi fido troppo di questi servizi ...
Ma forse sono solo troppo prudente.


 questioni ... Volevo evitare questa soluzione.
con questa architettura non ne vedo molte altre.
di orologi affidabili comunque ce n'e'.
uno mi sembra sia 
navy.mil
 (a meno che non abbiano momentaneamente messo su
il fuso del golfo persico).
la palla e' che se non lanci un prog free, l'utente almeno un clic deve
farlo, e visto il livello farebbe senz'altro shutdown.
quindi devi gestirti tu sta specie di "net time". codice in giro direi ce ne
sia.
fra l'altro, implica che le macchine siano connesse alla rete.
mi sorge il dubbio che non lo siano spesso.
non finisco di stupirmi come riescano a stare in attivo utenti di questo
tipo.
anzi, come la selezione naturale li lasci proprio esistere. c'e' qualcosa da
mettere a punto nella storia della variante vantaggiosa.
coraggio :)
ciao
alternativa: quando uno modifica chiama e dice "ehi ragazzi di la', occhio
che sto modificando..." :)

 perň se i computer sono sempre connessi ad internet (DSL o simile)
se lo fossero, gli converrebbe rendere pubblico il db di una delle sedi e
rifarsi sempre a quello...


[cut]

 Ma forse sono solo troppo prudente.
se sono nt, forse puoi provare
http://www.timeutilites.com/atcs.php


Ho gia' trovato del codice per NTP. Ci inseriro' una ventina di 
indirizzi di server ntp ...


 semplificare una tabella clienti.
...
Sto affrontando lo stesso problema e, escludendo (anche per garantirmi
applicabilità future) il database centralizzato (o di collettamento) via
internet (anche per problemi di rete non sempre disponibile o caduta del
server centrale), faccio così:
- Ogni rete locale deposita tutto quanto fa relativamente a ogni tipo di
variazione (ovviamente per gli archivi che si intendono sincronizzare). E'
assolutamente importante che le cose vengano depositate con qualche chiave
che garantisca l'assoluta cronologia/sequenza delle operazioni eseguite
dalle varie postazioni della rete locale
- Per ogni operazione deposito lo stato dell'intero record (non recordset)
prima e dopo la variazione.
- Periodicamente ogni "sede" esporta su un file di testo le sue operazioni,
sempre in ordine assolutamente cronologico. A chi? A chi vuole, anche più
d'uno.
- Chi "importa" il file (da vedersi però caso per caso) dovrà lavorare solo
sulle differenze, non sui valori assoluti, quindi sull'entità di una
variazione di quantità, non sulla nuova quantità e applicare la stessa
variazione sul sistema ricevente, in fase di sincronizzazione. Discorso
diverso può essere un'anagrafica: Non c'è "entità della differenza", quindi
mi cucco la nuova.
Questa "mia tecnologia" fa certamente al caso mio, con più punti di
sincronizzazione (in ingreesso e/o in uscita), se credi adattala ai tuoi
scopi...

 della rete locale
Io avevo capito che il punto della discussione fosse proprio questo
'dettaglio' della sequenza cronologica, difficile da gestire su due client
non sincronizzati.
Nel DB, stamattina: "Alberto è bello"
Client 1: "No, Alberto è bellissimo" 10.42 [Era: "Alberto è bello"]
Client 2: "No, Alberto è solo piacevole" 10.43 [Era: "Alberto è bello"]
Nel caso in oggetto ovviamente vince il client 1, perchè ha messo un valore
migliore nel DB, ma in generale, se l'orologio di Client 2 era avanti,
stasera come sarà l'anagrafica?
Alberto

 stasera come sarà l'anagrafica?
Secondo me vince il client2, nel senso che copre quanto scritto dal client1
(se gli orari indicati sono affidabili)
Che succede se due postazioni della stessa rete (unico server) cambiano la
Rossi SPA in SNC e, poi, in SRL? A parte la perdita delle quote, vale
l'ultima variazione. Se l'utente beve, mica possiamo riattivare il
proibizionismo. Berrebbe lo stesso, magari di nascosto, ma lo stesso...
Per cronologia (avevo aperto un post apposta tempo fa) non deve far fede
l'orario, ma la sequenza degli avvenimenti. Io uso un contatore mio (non un
autoincrementante) e, per assegnare il prossimo contatore (dopo aver
bloccato anche gli ascensori dell'azienda), rilevo il MAX e sommo 1, poi
libero anche i cani del canile.

 client1 (se gli orari indicati sono affidabili)
IMHO, il punto era proprio questo: come far sì che gli orari fossero
affidabili, avendo due client in due reti diverse, non connesse a Internet,
che si scambiano i dati in modalità batch alla sera, e a questo punto un
qualcosa dovrebbe decidere chi ha ragione...
Ciao
Alberto

Albe V° ha scritto:

Vero. Gli orari non sono affidabili. Forse sincronizzando con l'orologio del
servee... ma se qualche furbacchione cambia l'orologio che succede con
quanto già depositato? Preferisco il contatore...


Purtroppo anche i contatori sono separati, cioe' la sede centrale puo' 
solo avere un contatore per le sue variazioni e la sede distaccata idem. 
Quando devo sincronizzare il confronto tra contatori non mi serve.
Purtroppo con questa modalita' sconnessa mi sembra che un criterio 
"demagogico" non possa non essere presente: o prevale il master o 
prevale il piu' recente. Ovviamente nessuna delle 2 soluzioni e' ottimale.
Siccome devo sincronizzare solo anagrafica clienti e ordini (no 
magazzino, giacenze,ecc.) credo che utilizzero' la sincronizzazione col 
criterio del piu' recente e faro' in modo che gli orologi dei diversi pc 
si sincronizzino all'inizio della connessione per la 
trasmissione/ricezione dati con un server NIST.
Rimane comunque da decidere cosa fare quando, spero raramente, gli 
stessi record sono stati modificati ed avviene la prevaricazione. Come 
ho gia' detto, il livello degli utenti e' piuttosto scarso.
Se avete qualche suggerimento ...


 Se avete qualche suggerimento ...
nella tabella metti un paio di campi con login e data-ora dell'ultima
variazione, ed eventualmene metti i dati variati in una tabella log,
eventualmente consultabile (ma non editabile a mano). di piu' mi sembra
complesso.
ciao

 Se avete qualche suggerimento ...
Sì (scusa se insisto): Se l'operatore A decide che Rossi si chiama Mario e
l'operatore B, dopo, decide che si chiama Franco, sono cavolacci loro, mica
tuoi...

 
Supponi che A faccia una modifica alle 14.00
Alle 14.01 B fa una modifica allo stesso record.
B invia le modifiche
A riceve le modifiche e per la regola detta prima il recod di B 
sovrascrive quello di A.
A pero' si aspetta che il record contenga i suoi valori (potrebbe ad 
esempio trattarsi di un ordine).
Non posso dire al cliente che in questi casi sono cavoli suoi. I qualche 
modo questa situazione va segnalata, un po' come succede con le repliche 
di un db, se ci sono conflitti viene creata una tabella apposita.


 di un db, se ci sono conflitti viene creata una tabella apposita.
Ogni cosa, non l'ho mai negato, va valutata per le varie condizioni (e
anomalie/stranezze) che può creare. Questo concetto non muta qualunque sia
il sistema che si adotta per riprodurre transazioni diverse su archivi
"comuni", ma scollegati...