Newsgroup: it.comp.lang.visual-basic
Titolo: [?]Consiglio su sincronizzazione dati remota

Vorrei sostituire una procedura di sincronizzazione dati che ho 
installato presso un mio cliente con qualcosa di piu' valido ed efficiente.
L'attivita' del cliente e' sostanzialmente di vendita tramite agenti.
Presso gli uffici del cleinte e' installato l'archivio principale (in 
access) con relativo front-end per la gestione di ordini e fatturazione.
Li' si trovano:
- anagrafica clienti
- prodotti
- ordini
- fatture
Presso gli uffici degli agenti e' installata una versione ridotta che 
consente di effettuare ordini e di vedere lo stato dell'ordine.
Agli agenti e' consentito:
- inserire e/o modificare clienti
- inserire e/o modificare prodotti
- inserire e/o modificare ordini
E ora veniamo alle note dolenti. Per andare incontro alle esigenze del 
cliente (budget) la procedura di sincronizzazione dei dati non avviene 
in tempo reale, ma tramite email. I dati da sincronizzare vengono 
inseriti in un messaggio ed una procedura si occupa di interpretarli e 
di sincronizzare gli archivi degli agenti con quello principale e viceversa.
In linea di massima il meccanismo funziona, ma solo in linea di massima.
Essendo il meccanismo di sincronizzazione differito quando vengono 
modificati dati sia sul db principale che su quello di un agente, si 
possono verificare parecchi conflitti ( che devo risolvere io ).
Ed il debug e' piuttosto complicato.
In poche parole ne' io ne' il cliente siamo soddisfatti di questo 
accrocchio.
Volevo passare a qualcosa di piu' sofisticato e sicuro.
Ovviamente rimangono i limiti di budget, per cui pensavo a qualcosa di 
questo tipo:
- cliente si fa assegnare un indirizzo ip
- l'archivio (sempre in access) diventa disponibile tramite un qualche 
tipo di "server"
- gli agenti usano questo "server" per la sincronizzazione
Vorrei evitare di dover installare, gestire web server o altro, per cui 
l'ideale sarebbe un qualche servizio legato direttamente ai dati (un ado 
server) che permetta l'accesso sicuro dall'esterno agli stessi.
Il cliente non ha ne' la struttura per avere un amministratore di 
sistema che controlli/gestisca servizi/server/sicurezza di questo 
sistema, ne' me ne voglio occupare io.
Vorrei anche limitarmi il piu' possibile all'uso di vb, nel senso che 
non conosco asp, php e non ho tempo adesso di studiarli.
Avete qualche suggerimento?
grazie
	maxx
-- 
NOSPAM: Rimuovere i trattini dallo username!
Cut hyphens from my username!

 risolvere io ).
Quando più posti di lavoro (o sedi/filiali/uffici) possono fare un po' di
tutto, personalmente non vedo altra soluzione che quella di depositare solo
le differenze prodotte da un certo posto di lavoro (in termini di valori e
di campi interessati), non i risultati finali.
In questo modo tutti possono fare tutto e tutti possono tener conto di
tutto.
Mi spiego: Se modifico un a riga d'ordine di una quantità e un valore (sono
esempi) manterrò da qualche parte, con riferimento preciso a quella riga, le
differenze in più o in meno dei soli campi variati. E' evidente che se si
tratta di campi descrittivi il concetto di differenza non è applicabile e
quindi (IMHO) vale la regola dell'ultimo che arriva meglio si accomoda,
esattamente come accade in un ambiente di rete locale. Se non esiste un
riferimento (sto aggiungendo una riga) le differenze interessano tutti i
campi, se sto eliminando un riferimento (sto eliminando una riga) basta un
segnale.
Un altro problema è costituito dalla numerazione dei documenti, per evitare
doppioni dovuti all'assenza di centralizzazione: l'ordine nuovo creato da un
posto di lavoro non deve essere confuso con l'ordine (nuovo o vecchio)
creato da un altro posto di lavoro, insomma, i documenti devono avere una
numerazione separata (magari provvisoria) per posto di lavoro.
Salvo un archivio centralizzato sul web (ma se un posto di lavoro non può
accedere o il server web si ferma?), il vari "diari" devono essere
depositati su archivi locali da sincronizzare periodicamente con gli archivi
di lavoro allo scopo di ottenere quest'ultimi perfettamente aggiornati in
modo da poter cancellare i diari già integrati.
L'ordine di integrazione non potrà essere rispettato in nessun caso (gli
orologi possono essere sregolati), quindi tanto vale non contarci. I
problemi che ne nascono (trovo un segnale di cancellazione riga e poi, da
altro diario di altro posto di lavoro, una variazione della stessa riga, che
fare?...) possono imporre modalità operative (non è possibile cancellare
righe) o comportamentali automatiche (ignoro variazioni a righe eliminate)
che non esisterebbero nel trattamento in tempo reale, ma, tant'è, ... se il
tempo reale non si può avere...
Quanto a grandi linee ho cercato di spiegare è applicabile (con le
eventuuali limitazioni) anche non disponendo/usando il web e con
"sincronizzazioni" molto dilatate nel tempo (tanto non saranno mai, pur se
frequenti, corrispendenti alla realtà...) per cui le modalità di ricezione
dei diari (mail, floppy, FTP, etc.) non sono più importanti, come non lo è
(nè deve essere perchè mai vero) l'ordine di sincronizzazione.
C'è stato in passato qualche topic sull'argomento...

 C'č stato in passato qualche topic sull'argomento...
Ancora tu? ;-)
http://makeashorterlink.com/?W2C655E18


Ciao. Quando dici: "gli agenti usano questo server per la sincronizzazione"
intendi dire che
a) io agente inserisco i miei clienti ed i miei ordini in locale e poi alla
sera mi collego e sincronizzo
oppure
b) che io agente mi collego ed inserisco i dati direttamente sul db centrale
(che quindi mi da' in tempo reale un riscontro sulla correttezza dei dati
inseriti)
Nel caso A chiaramente avrai gli stessi identici problemi di conflitti della
soluzione che stai utilizzando ora. Mi piacerebbe sapere attualmente se
l'agente 1 crea un nuovo cliente ed anche l'agente 2 fa la stessa cosa, alla
sera quando sincronizzano come risolvi il conflitto?
Nel caso B invece obbligheresti gli agenti ad inserire per forza i dati in
un'unica soluzione (solitamente alla sera) e a molti questo non piace. Se
pero' sono monomandatari penso che l'azienda possa forzare la mano....  In
ogni caso per questa soluzione io ti consiglio caldamente di mettere in
piedi un bel sito web. Anche se non conosci l'ASP puo' essere una buona
occasione per imparare e sicuramente ti puo' essere + utile che mettere in
piedi un "ado server" (che per quel che ne so dovresti crearti da solo)
lavorando di winsock.
Buona fortuna
-- 
Fabio
http://www.codice.it

 sera quando sincronizzano come risolvi il conflitto?
non solo, il dubbio per me è anche un altro....
supponiamo che ci siano 3 agenti, ognuno all'inizio con lo stesso identico
database.
poi ciascuno dei 3 agenti inserisce altri 3 clienti nel database, ma
supponiamo che vengano inseriti in ordine diverso.....
per dire, all'inizio ho 100 clienti.....poi succede quanto segue:
AGENTE1 inserisce A, B, C
AGENTE2 inserisce B, A, C
AGENTE3 inserisce C, B, A
ogni nuovo cliente avrà un ID diverso, ovviamente......solo che quello che
per l'agente1 è rappresentato dall'ID=104, per dire....non sarà lo stesso
per gli altri due agenti......
insomma, potrebbe nascere pastrocchi non semplici da gestire.....
come fai a gestire questo accavvallamento di informazioni (bello questo
termine *tecnico*:-)
te lo dico uno che circa 6-7 anni fa si era imbattuto in una situazione di
questo tipo....e alla fine ci aveva rinunciato.......
forse ero troppo giovane ed inesperto, ma anche oggi mi fanno sempre un po'
paura.....
concordo con il post di Mino: la soluzione ideale oggigiorno è un bel server
web+[asp|php] o tecnologie analoghe.....
ci sono anche innumerevoli vantaggi: non devi gestire client (inteso come
aggiornamento del software), database unico da gestire (sicurezza, backup,
etc.), ogni agente vede in tempo reale la situazione (immagina le giacenze
di magazzino).
good coding!!!
--
Alletun
"Se ti va di spassartela adesso
Prendi il Vettore oggi stesso."
Terre Desolate - Stephen King

 di magazzino).
Forse, solo che dovrei ripartire da zero e far pagare a qualcuno tutto 
il lavoro ... :-(


 
Sempre lo stesso programma infatti, lo ho dato al cliente, ma ogni 10 
giorni salta fuori un problema di sincronizzazione nuovo. Siccome tutti 
i diagrammi di flusso che ho fatto per gestire i vari casi occupano 
ormai decine di pagine ed il debug e' lento e complicato, devo trovare 
qualcosa di nuovo.
Quel thread mi ha dato qualche spunto, ma in realta' non mi ha spinto 
verso una "regola" da dare alla sincronizzazione.
Come dice Mino Fabio pero', non se ne esce, o si lavora in tempo reale 
nel qual caso dei "normali" lock sui record sarebbero sufficienti a 
gestire la sincronizzazione o il problema rimane.
Forse sono io che non riesco a cogliere il problema nella sua interezza 
ed a tirare fuori dal cappello la soluzione giusta. :-(


 inserire i prodotti.
Giusto, ma che accade se in un'azienda con LAN locale 3 operatori
inseriscono lo stesso cliente?
C'è qualcosa che non va nell'organizzazione... Comunque, sì, può accadere:
due operatori inseriscono bolle di vendita, alla rinfusa (e non come
andrebbe fatto, in ordine cronologico, ma come potrebbero essere due?), ...
beh, il sistema o, in assenza/carenza, l'operatore, dovrebbe preoccuparsi di
segnalare se quel cliente esiste già (per esempio tramite P.IVA o CF)

 interezza ed a tirare fuori dal cappello la soluzione giusta. :-(
Cerca di capire tutto quanto può avvenire, immaginane in conflitti possibili
e vedi di trovare soluzioni. Per quelli senza soluzione vedi se è possibile
impedire (operativamente o automaticamente) che il conflitto si presenti.
Davvero, non c'è verso di poter fare tutto e personalmente ho escluso l'uso
del web. Se il server si ferma non è pensabile che tutto (azienda e agenti)
si fermi. Nè, ancora oggi, è pensabile di poter contare su una connessione
Internet sempre e ovunque, ... sto pensando agli agenti viaggiatori, i porta
a porta, quelli che fanno la tentata vendita...

 Avete qualche suggerimento?
http://www.nicolaottomano.it/public/MyWebServer.zip
bye
-- 
Esistono 10 tipi di persone: chi conosce il binario e chi no.
Gestione Ottica - Gestionale per Ottici e Programmi Gratuiti su:
http://www.nicolaottomano.it

 
Gli daro' un'occhiata, ma ti faccio una domanda un po' provocatoria. 
Cosa succede se qualcuno tenta di bucare il tuo webserver, quali test di 
sicurezza hai fatto?


 di sicurezza hai fatto?
E' un webserver di prova. La sicurezza devi implementarla. E' una cosa che
ho spiego in "prova.htm".
E' chiaro che la sicurezza devi gestirla in base alle esigenze del cliente.


Posso dirti per esperienza che purtroppo non esiste una soluzione valida per
tutti (o meglio non esiste una soluzione automatica per risolvere i
conflitti valida per tutti). Mi sembra di capire che scarti a priori una
soluzione web (o simili) e quindi tralascio discorsi sulla sicurezza,
eventuali vpn, ecc. ecc (la butto li' ma non voglio sconvolgerti la vita: e
se metti un bel server W2000S o W2003 con servizi terminal attivati e
protetto da una semplice VPN? Usi il tuo programma cosi' com'e' e via)
Se vuoi continuare con la sincronizzazione in differita e se ho ben capito
le esigenze del tuo cliente, la mia opinione per il tuo specifico caso e'
questa:
1) Fai capire al cliente che tu cerchi di risolvergli i problemi ma in
qualche caso forse dovra' cambiare il modo di lavorare, se vuole che tutto
funzioni a dovere
2) I dati/tabelle da sincronizzare dovrebbero essere i seguenti:
   - anagrafica clienti
   - prodotti
   - ordini
   - fatture
 e secondo me ognuno va analizzato separatamente perche' presenta
problematiche diverse
2a) Clienti
 Se ogni agente ha i propri clienti non credo avrai grossi problemi (anzi
secondo me non li hai nemmeno adesso). Segui i suggerimenti di Lupo e magari
metti dei bei vincoli sul programma. Per esempio se io sono l'agente 3 posso
creare e vedere solo i miei clienti e magari (se il tuo cliente te lo
concede) sono anche l'unico che li puo' modificare. In questo caso i
conflitti sono veramente minimi. Per la codifica io ho sempre utilizzato un
sistema del tipo:
   Supponiamo che prevedi un max di 20 agenti
   La sede centrale quando crea un nuovo cliente con chiave primaria
1,21,41,61,81,101, ecc. ecc.
   L'agente 1 quando crea un nuovo cliente con chiave primaria
2,22,42,62,82,102, ecc. ecc.
   L'agente 2 quando crea un nuovo cliente con chiave primaria
3,23,43,63,83,103, ecc. ecc.
   ecc.
 cosi' non hai conflitti nella codifica della chiave primaria
2b) Prodotti
  Il discorso prodotti e' gia' piu' complesso in quanto ci sono diverse
informazioni che vanno trattate separatamente (e quindi spero tu avrai gia'
+ tabelle separate). Per quanto riguarda l'anagrafica (quindi descrizione,
unita' di misura, ecc.) usa lo stesso sistema dei clienti (pero' onestamente
io non farei codificare dei nuovi prodotti a degli agenti, non capisco come
fa a lavorare in questo modo il tuo cliente)
  Poi ci sono le quantita': siccome il magazzino immagino sia dove c'e' la
sede centrale (dove vengono anche fatti carichi e scarichi di magazzino)
penso che le disponibilita' di magazzino sia sufficiente inviarle solo dalla
sede verso gli agenti (e non viceversa) quindi il problema dei conflitti non
esiste
  Poi i listini: come per le quantita' spero che chi decide i prezzi di
vendita dei prodotti sia la sede centrale e non gli agenti. Quindi anche in
questo caso invio monodirezionale
2c) Ordini
  Come per gli agenti il nonplusultra sarebbe convincere il tuo cliente che
se un agente crea un ordine e' solo lui che lo puo' modificare. Se riesci a
convincerlo risparmi un sacco di tempo e di problemi. Se invece il cliente
non ci sta, segui i suggerimenti di Lupo che sono ottimi, avrai un bel po'
da lavorare pero'
2d) Fatture
  Questi mi sembra di capire che vanno dalla sede centrale verso gli agenti
e non viceversa quindi immagino non avrai problemi nemmeno adesso.
3) Ultimo, ma non meno importante, se vuoi fare un bel lavoro c'e' da
perderci del tempo quindi fatti pagare bene (e fai capire al cliente che se
investe poco ottiene anche poco). Almeno questa e' la mia opinione poi vedi
tu.
Ciao
-- 
Fabio
http://www.codice.it

 opinione poi vedi tu.
Questa e' la parte minore del problema. E' ovvio pero' che essendo un
programma sviluppato a pacchetto e non a giornate non posso chiedere al
cliente 30 giornate perche' quello e' il tempo che mi occorrera' per
stabilire tutte le combinazioni durante la sincronizzazione. Ed essendo
un programma con delle specifiche abbastanza particolari richieste da
questo cliente e' improbabile che si riesca ad ammortizzare il tempo
vendendo il programma ad altri.


 inserimento dati da parte degli agenti "live".
A quanto ammonta circa il budget mensile del cliente?
Perchè con 30 euro si mette una ADSL flat e un bel pc acceso nelle ore di
ufficio.
E, invece del webserver che ti ho consigliato, puoi usare una struttura
Client\Server con gestione dei dati via winsock (e critti le comunicazioni).
Io ho creato una infrastruttura del genere per Gestione Ottica (viene creato
un Network Virtuale fra le sedi). Ho il mio protocollo di comunicazione e
critto i dati con AES Rinjdael. Credo che potresti approcciare il problema
con questo metodo.


 
Ho pensato anch'io ad una soluzione di questo tipo, ma ci sono 3 ordini 
di problemi:
1. cliente ed agenti sono in Svizzera ed e' un po' piu' complicato per 
me interessarmi di tutto quello che serve.
2. non c'e' volonta' da parte del cliente di spendere soldi per creare 
una "struttura" per gli agenti, i quali sono spesso di tipo volatile 
nonche' home. E' impensabile che il mio cliente costringa un suo agente 
a mettersi l'adsl in ufficio o a casa, quando non sa per quanto tempo 
l'agente lavorera' per lui e quando l'agente gli dira' che
fa prima a mandargli un fax con gli ordini scritti su apposito modulo.
3. non c'e' l'esigenza di avere l'aggiornamento dei dati in tempo reale 
e quindi e' difficile per me spingere per una soluzione costosa solo 
perche' quella da me implementata non funziona sempre. Gli agenti 
possono inserire gli ordini e fare la sincronizzazione 2 volte la 
settimana senza che il business ne risenta.


 modifiche fatte in sede sovrascrivono quelle dell'agente.
In termini di sincronizzazione, la sede può (dico può, non deve) essere
considerata un posto di lavoro come un altro, come il PC di un agente, come
quello di un altro agente...
Una (un'altra) soluzione di pseudo-sincronizzazione che ho adottato (ma che
riguarda solo gli ordini) è questa: in un certo instante (al mattino) si
duplicano pari-pari su tutti i PC (portatili) degli agenti gli archivi
aziendali, coprendo quelli già presenti sui PC stessi. La sede e gli agenti
lavorano per tutta la giornata sui rispettivi archivi locali. Unica
imposizione: numerazione separata (e univoca) dei documenti. Alla sera i
portatili degli agenti tornano in sede e vengono collegati alla rete
aziendale (oppure spediscono i loro archivi alla stessa) e si provvede alla
sincronizzazione che altro non è che l'integrazione (con aggiornamento
contestuale di qtà/valori e progressivi) dei nuovi documenti di competenza
dello specifico agente negli archivi aziendali. Non vi è conflitto perchè i
documenti sono univocamente individuabili. L'unica attenzione (fatta appunto
per differenza) sono le evasioni, nel senso che la sede può avere nel
frattempo evaso lo stesso ordine che già esisteva ieri. Con opportuni
adattamenti si possono gestire anche eventuali consegne fatte dagli agenti,
quindi con bolle (ma sempre su bollettari diversi), recupero crediti, etc.
Alla fine di tutto si riduplicano gli archivi sui portatili degli agenti. Se
un agente non può rientrare? Pace, i suoi dati verranno integrati negli
archivi aziendali solo quando si potrà e l'agente, a sua volta, avrà archivi
completi e aggiornati solo in quel momento.

 settimana senza che il business ne risenta.
Allora imponi degli orari di accensione del server.
Gli agenti intanto modificano i dati in locale e tramite una app Client, li
passano all'azienda.
Sui DB metti dei flag per identificare i record modificati.
E poi mandi solo quelli all'azienda.
In ultima analisi, se proprio vuoi continuare col metodo tuo, puoi
identificare gli ordini in questo modo:
CodAgente+CodOrdine
e il codice lo fai generare direttamente dall'agente e non dalla sede.


 e il codice lo fai generare direttamente dall'agente e non dalla sede.
Cioè un server web da usarsi solo per trasferire dati in ritardo.
emmexx aveva già le mail...
Con tutti i problemi di sincronizzazione che restano. Identici.

 imposizione: numerazione separata (e univoca) dei documenti. Alla sera i
 >
Anche questa e' una soluzione possibile, pero' nel mio caso gli agenti 
lavorano sempre lontano, non rientrano in sede, quindi tutto deve essere 
fatto da remoto (in alcuni casi con modem 56k).


 Con tutti i problemi di sincronizzazione che restano. Identici.
No il server web in questo caso lo accantoniamo.
Io dico.
può creare un ordine già numerato. Il numero lo dà l'agente.
Mi spiego.
E' inutile che l'azienda lavori con 001, 002, 003 ecc.. come codici ordine.
Invece mi sembra meglio che il codice sia dato dall'agente.
Il quale conosce a priori che numero prograssivo deve fare.
Esempio
Agente1 = AGN1
Agente2 = AGN2
Agente1 fa un ordine e lo chiama: AGN1-0001
Agente2 fa un ordine e lo chiama: AGN2-0001
e il 0001 aumenta di 1 ogni volta che l'agente fa un nuovo ordine.
Agente1 fa un nuovo ordine e lo chiama: AGN1-0002
Poi la Sede elabora gli ordini suddividendoli per agente.


 essere fatto da remoto (in alcuni casi con modem 56k).
E che ti costa spedire (nei due sensi, se necessario) in TXT zippato
allegato alla mail con i nuovi ordini e righe ed eventuali variazioni alle
righe precedenti? Ma forse questo è quello che già fai...

 
Come ha gia' detto Lupo, il problema rimane: devo far sincronizzare i 
dati in maniera coerente.
Chiarisco meglio la radice del problema, perche' mi sa che abbiamo un 
po' divagato.
La sincronizzazione avviene piu' o meno in questo modo:
agente:
1. viene creato o modificato un record (o piu' record)
2. il/i record creati o modificati vengono trasmessi
3. attesa dei record riformattati dalla sede(identifativo unico, 
numerazione, ecc.)
4. se i record creati/modificati non sono stati riformattati vengono 
inviati nuovamente
4.bis se i record riformattati sono stati ricevuti, invio di conferma 
ricezione.
sede:
1. ricezione dei nuovi record e riformattazione
2. invio dei record
3. attesa conferma
Ovviamente, a parte alcune regole particolari per alcuni tipi di record 
la procedura e' simmetrica, cioe' sia la sede che gli agenti possono 
creare/modificare record che devono essere 
inviati/riformattati/confermati dalla controparte.
Il protocollo in linea di massima funziona, come ho detto, tranne in 
alcuni casi o che non ho considerato o in cui ho risolto gli eventuali 
conflitti in maniera troppo semplicistica non considerando tutte le 
possibili combinazioni di trasmissioni/conferme.
ciao


 Il quale conosce a priori che numero prograssivo deve fare.
Ok, è quello che consigliavo io: numerazioni (pur progressive), ma separate
fra sede e varie agenti (anche far agente e agente, ovvio). Resta comunque
il problema delle modifiche (aggiunte/eliminazioni/variazioni) fatte dalla
sede e/o dagli agenti su articoli e righe...

 Io non lo firmo, anche se mi fido.
Per "mio cliente" intende l'azienda
<vb code>
Dim MioCliente as  Emmexx.Cliente
</vb code>


 possibili combinazioni di trasmissioni/conferme.
Allora crea qualcosa del tipo
CodAgente-CodOrdine-NumRevisione.
E' chiaro che le revisioni vengono fatte con valori progressivi.
Inoltre l'agente riceve sempre eventuali revisioni dell'azienda e decide se
accettarle o annullare l'ordine.


 
Esatto. Solo che e' inutile prevedere aggiornamenti giornalieri perche' 
poi gli agenti stanno in giro per clienti una settimana e si inseriscono 
gli ordini tutti insieme. Fare la sincronizzazione dell'intero archivio 
sarebbe inutile e fare solo quella dei dati relativi ad un agente e' 
l'oggetto del mio piagnisteo... :-)


 
Credo che dovresti provare a fare un'implementazione per cominciare ad 
apprezzare il livello di difficolta'. Solo il pensiero della scrittura 
di un diagarmma di flusso per gestire trasmissione/ricezione mi fa 
venire i brividi. Ma probabilmente si tratta semplicemente di un mio 
limite ...


 limite ...
Io ho risolto col metodo del Network Virtuale. Tu purtroppo sei vincolato
dal budget ristretto e da situazioni un pò più complesse delle mie. I limiti
si possono superare, ma ill problema è sempre lo stesso: quanto è disposto a
spendere il cliente per maggiore affidabilità?
