Sincronia dbms con ado

domenica 20 febbraio 2005 - 21.28

kevin Profilo | Junior Member

Ciao a tutti,
volevo chiedervi un consiglio ,
dovrei fare un'applicazione che fa uso di dbms,
il problema è che l'applicazione è installata in 3 sedi e vorrei sapere come potrei mantenere tutti e tre i dbms aggiornati, questo perche nelle 3 sedi i dbms vengono modificati e ogni ora tutti i dbms devono essere aggiornati con le modifiche effettuate nelle altre sedi.

Io avevo pensato, visto la presenza di un piccolo server di usarlo per mettere su un dbms sul quale fare operare i programmi, ma loro ho bisogno che le applicazioni in assenza di linea funzionino lo stesso, allora avevo pensato che un file con il dbms access venga salvato nel server ftp e ogni applicazione salvi su un file tutte le mofiche fatte al dbms dall'ultimo aggiornamento, quindi ogni ora il dbms di ogni applicazione viene aggiornato con le operazioni eseguite dalle altre 2 leggendo il file txt e applicando le operazioni al dbms locale.
Solo che questo metodo nn mi da molta fiducia.

Qualcuno mi puo consigliare qualcos'altro?

Grazie 1000

Brainkiller Profilo | Guru

Ciao Kevin,
ma tu che RDBMS stai usando ? Access non è un vero RDBMS.
Se usi SQL Server ci sono diverse tecniche per mantenere in sincronia i database e sono ben spiegate nei Books On Line.

ciao
david

kevin Profilo | Junior Member

Non ho ancora deciso cosa usare, avevo pensato ha dbms access, cosi ho la possibilita di usarli su qualsiasi pc senza aver un server con dbms(i dati che dovrebbe gestire sono pochi e basterebbe anche access),
il mio problema piu grande e mantenere i 3 dbms aggiornati, con le modifiche che sono state effettuate.
Cosa mi consigli?
Il server che ho ha disposizione monta gia mysql.

GRazie

Brainkiller Profilo | Guru

Il problema con Access è che non è predisposto per fare questo tipo di operazioni.
Viene utilizzato quasi sempre su un computer locale o in reti di piccole dimensioni con una parte server e più parti client che si collegano.
Brutalmente la cosa più rapide per tenere tutto in sincronia è fare le copie del file .mdb e distribuirle però convieni anche tu che non è un metodo molto bello, perchè se tu dal client A modifichi qualcosa, il client B non vede la modifica fino alla nuova copia.

ciao
david

kevin Profilo | Junior Member

cosa mi consigli di usare al posto di access?
Il problema è che io vorrei fare un modo che ogni applicazione sia indipendente, con questo voglio dire che se nn c'è linea l'applicazione puo continuare a lavorare senza nessun problema e appena torna disponibile la connessione, viene aggiornato il dbms.

kevin Profilo | Junior Member

ma potrei far fare l'unione delle tabelle ogni ora con access?

http://msdn.microsoft.com/library/ita/default.asp?url=/library/ITA/vbcon/html/vbconintroductiontodatasetupdates.asp

cosa ne pensi?

Grazie

Brainkiller Profilo | Guru

Si ma prendi l'esempio che ti ho fatto io:
Se ci sono 3 client e tu fai aggiornamenti ogni ora, e nel DB hai una tabella Clienti... se il client C ti cancella un cliente e per qualsiasi motivo il client B ti crea un ordine per quel cliente poi come fai dopo un'ora ?

ciao
david

kevin Profilo | Junior Member

Si hai ragione, cosa potrei usare?

Grazie

alextyx Profilo | Expert

Scusate l'intromissione....il problema è interessante. Può darsi che prima o poi me lo ritrovi di fronte anch'io. Nn mi sembra che SQL server piuttosto che MDB risolva un problema di aggiornamento qualora le comunicazioni siano assenti fra i tre client. Secondo me è un problema da risolvere a livello di analisi dell'applicazione. Nn lo si può affrontare facilmente senza conoscere dei dettagli che probabilmente sarebbe troppo complicato e lungo far passare sul forum. Ho in mente, comunque, dei gestionali (magazziono/bollettazione) della IPSOA, che mi pare risolvano il problema mettendo insieme i dati ogni tanto, ma è ovvio che ogni client deve avere una certa indipendenza e magari emettere bolle con un suffisso proprio, così da distinguerne la numerazione da quelle emesse dai suoi 'colleghi'! Un cliente che fa un ordine, lo si reinserisce al volo :-) Tuttavia potrebbe comunicare ad uno solo dei tre client una variazione dei suoi dati. Anche qui, il problema è organizzativo. La modifica potrebbe avvenire sul client che ne è a conoscenza ed essere comunicata il prima possibile agli altri, fidando sul fatto che lo stesso cliente nn richieda contemporaneamente documenti anche agli altri e che, in caso contrario, si premuri di comunicare anche a loro le stesse variazioni. Secondo me queste situazioni costringono ad una scelta di fondo: O si seguono procedure rigide, che (a titolo di esmpio) rifiutano un cliente nn registrato sul DB centralizzato, o che comunichi dati diversi dagli utlimi in nostro possesso e quindi possono rallentare e burocratizzare il lavoro, oppure si sceglie una via più snella, che però lascia dei margini di incertezza. Un'azienda grande e strutturata, forse opterà x la prima. Una più piccola ed aggressiva, probabilmente sceglierà la seconda!
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !
Copyright © dotNetHell.it 2002-2024
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5