Oppure

Loading
12/01/12 10:38
trattobasso
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.
aaa
12/01/12 12:21
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" ...
12/01/12 16:27
Snogar
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:
aaa
12/01/12 17:37
Renny
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.
aaa
13/01/12 11:11
Snogar
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.
aaa