Questo sito utilizza cookies, anche di terze parti, per mostrare pubblicità e servizi in linea con il tuo account. Leggi l'informativa sui cookies.
Username: Password: oppure
C# / VB.NET - vb.net 2010 e db access
Forum - C# / VB.NET - vb.net 2010 e db access

Avatar
trattobasso (Normal User)
Pro


Messaggi: 89
Iscritto: 02/05/2007

Segnala al moderatore
Postato alle 11:38
Giovedì, 12/01/2012
buongiorno a tutti,volevo chiedervi un consiglio riguardo la migliore "architettura" da utilizzare per sviluppare un applicazione vb.net che lavori su un database access. Il file mdb deve risiedere in una cartella remota H: condivisa che si trova locata in una sede diversa da quella di dove si trovano tutti i computer che utilizeranno l'applicazione. Questo è l'unico vincolo che devo rispettare oltre al tipo di database: mbd.
Deto questo ho fatto diverse ricerche e sembra ci siano diversi modi di sviluppare l'applicazione ma sincermanete non so quale sia più adatto.
Considerando che ci saranno n utenti che consultano e 3 che inseriscono dovrei/potrei:
1) Copiare il databse sui client e collegare le tabelle al mdb che si trova sul server e da vb.net lavorare sul mdb in locale che dovrebbe aggiornarsi con la copia che si trova sul server.
2) Far lavorare tutti i client direttamente sul server.
In entrambi i casi so che dovrò in qualche modo gestire la modifica dei dati contemporanea dei 3 utenti ma troverò un modo.
Voi cosa suggerite metodo 1 o 2 oppure ce ne sono altri migliori.

Grazie dei suggerimenti a tutti.

PM
Avatar
nessuno (Normal User)
Guru^2


Messaggi: 5462
Iscritto: 03/01/2010

Up
1
Down
V
Segnala al moderatore
Postato alle 13:21
Giovedì, 12/01/2012
Prima di tutto non è possibile non dire che la scelta di un mdb è assurda.
In questi casi è necessario utilizzare un vero DB Server (SQL Server, MySql ...) installandolo in una macchina disponibile in rete e visibile da tutti gli altri  PC.

Nel caso di un mdb, puoi far lavorare direttamente i client su server.

In ogni caso devi gestire la "concorrenza" dato che avrai più client che possono modificare i dati contemporaneamente (potrai utilizzare una "concorrenza ottimistica").

Infine, dato che un mdb ha forti possibilità di "corrompersi" (per vari motivi, su cui non si può intervenire) dovresti lavorare sempre usando delle "transazioni" ...

Concordo per la scelta del db purtroppo devo attenermi a questa condizione,sono cosciente della concorrenza e studierò al meglio la questione ma,scusa l'ignoranza cosa intendi per "transizioni"?Grazie intanto per i consigli che mi hai dato. - trattobasso - 12/01/12 17:25
Concordo per la scelta del db purtroppo devo attenermi a questa condizione,sono cosciente della concorrenza e studierò al meglio la questione ma,scusa l'ignoranza cosa intendi per "transizioni"?Grazie intanto per i consigli che mi hai dato. - trattobasso - 12/01/12 17:26
Concordo per la scelta del db purtroppo devo attenermi a questa condizione,sono cosciente della concorrenza e studierò al meglio la questione ma,scusa l'ignoranza cosa intendi per "transizioni"?Grazie intanto per i consigli che mi hai dato. - trattobasso - 12/01/12 17:26
Transazioni non transizioni ... http://it.wikipedia.org/wiki/Transazione_(database) - nessuno - 12/01/12 20:25


Ricorda che nessuno è obbligato a risponderti e che nessuno è perfetto ...
PM
Avatar
Snogar (Normal User)
Pro


Messaggi: 130
Iscritto: 09/01/2012

Up
0
Down
V
Segnala al moderatore
Postato alle 17:27
Giovedì, 12/01/2012
Crea un programma sul server che va a metter mano al file mdb e che parla con i programmi client, questi si limiteranno a parlare col programma sul server e sarà quest'ultimo a fare tutto gestendo concorrenza e simili ma operando sul DB come singolo utente .....e il gioco è fatto!  :k:

grazie snogar del suggerimento che probabilmente si avvicina molto di più ad una soluzione professionale rispetto a quello che purtroppo sono ancora in grado di fare...daltronde è la mia prima applicazione "gestionale" con database e quello che mi suggerisci tu è decisamente fuori dalla mia portata - trattobasso - 12/01/12 21:23
credo che per il momento mi limiterò a far lavorare tutti sul db gestendo le concorrenze e anche se non ho chiaro il concetto delle transizioni, vorrà dire che farò un backup del db ogni tot di tempo in modo da aver qualcosa da recuperare. - trattobasso - 12/01/12 21:25


PM
Avatar
Renny (Normal User)
Expert


Messaggi: 231
Iscritto: 30/07/2011

Up
0
Down
V
Segnala al moderatore
Postato alle 18:37
Giovedì, 12/01/2012
Un idea sarebbe fare come suggerito da Snogar, ma vuol dire scrivere tu tutta la parte di visualizzazione e modifica dei recordset. O meglio, scrivere delle classi che ti stiano al posto delle tabelle che hai nel database e che verranno visualizzate dai clients. Le modifiche apportate a questi oggetti puoi si ripercuoteranno sul DB tramite il programma server, che sarà l'unico che può agire direttamente al database mdb...Credo.


In attesa della fine del mondo, fissata per l'anno prossimo, sono alla ricerca di un notaio con cui fare testamento...
PM
Avatar
Snogar (Normal User)
Pro


Messaggi: 130
Iscritto: 09/01/2012

Up
0
Down
V
Segnala al moderatore
Postato alle 12:11
Venerdì, 13/01/2012
trattobasso inizia con il programma serve e sviluppalo come se fosse un programma per un singolo utente che deve gestire il db, ripeti la cosa con il programma Client ma SOLO per quanto riguarda l'interfaccia grafica di esposizione delle info, il codice busines sarà differente in quanto creerai una "chat" a cui ogni comando tipo "Inserisci Record" che sul server risponde al codice SQL, sul client sarà un comando per la chat che invierà al server cosa vuoi (nel nostro caso Inserisci record) e lo eseguirà reinviandoti sempre tramite chat quello che ti serve sul programma client.

Ora non so a che livello tu sia ma credo che questa soluzione sia banale se conosci un po di sql, ti scopiazzi da qualche parte il funzionamento delle chat multiutente "non so se qui su tofy c'è già qualcosa di pronto" e ti limiti a creare un protocollo di comunicazione per inviare e ricevere le operazioni SQL che vuoi far fare al programma server.

ah...il livello è abbastanza diciamo...apprendista! ma visto che lo scopo è proprio apprendere accetto il suggerimento, ti ringrazio e ci provo. - trattobasso - 17/01/12 02:00


PM