View Full Version : VB e database ad hoc: come si fa a...
Premessa
Mio padre programma in VB e gli faccio quel poco di grafica che c'è nei programmi.
E' un programmatore vecchia maniera: non usa i DB moderni (tipo sql et similia) ma crea delle tabelle ad hoc. Le tabelle sono semplici files di testo.
Problema
Il programma è in rete: i database sono su una macchina "server" (che ha poi il suo bel programma lato server) e ci sono dei clients che scrivono sul database. Purtroppo anche contemporaneamente: il che genera dei problemi.
Come fare ad impedire l'apertura del file dopo che è stato aperto già da un client ed evitare doppioni di files, o imputtanamenti vari?
Grazie a tutti!
p.s. Sono bene accetti anche consigli su libri che trattano l'argomento :)
E' dura...
Capisco che possa essere un programmatore vecchia maniera ma almeno digli di utlizzare access.
Eventualmente povrebbe fare uno sforzo per creare delle funzioni ad hoc e poi
richiamare quelle mascherando così l'utilizzo del db.
Se proprio vuola utilizzare i file secondo me come ho detto all'inizio non ci sono soluzione sicure al 100%, potrebbe andarti bene se hai pochi utenti e se i file sono piccoli ma se i file sono grandi secondo me sei fregato...
Se a tuo padre serve materiale posso passarti qualche link...
E' dura...
Capisco che possa essere un programmatore vecchia maniera ma almeno digli di utlizzare access.
Eventualmente povrebbe fare uno sforzo per creare delle funzioni ad hoc e poi
richiamare quelle mascherando così l'utilizzo del db.
Se proprio vuola utilizzare i file secondo me come ho detto all'inizio non ci sono soluzione sicure al 100%, potrebbe andarti bene se hai pochi utenti e se i file sono piccoli ma se i file sono grandi secondo me sei fregato...
Se a tuo padre serve materiale posso passarti qualche link...
Lui ha intenzione di passare a database tipo access, ma non adesso. Se mi passi qualche link mi fai un grosso piacere, grazie.
Ragazzi, avrei bisogno anche di sapere se esiste qualche libreria on line specializzata in testi informatici, dove acquistare testi sull'argomento...tnx
Lui ha intenzione di passare a database tipo access, ma non adesso. Se mi passi qualche link mi fai un grosso piacere, grazie.
Potresti guardare
http://www.vbitalia.it/
in particolare:
http://www.vbitalia.it/database/lezionedb4.asp?lez=lezionedb4
Ragazzi, avrei bisogno anche di sapere se esiste qualche libreria on line specializzata in testi informatici, dove acquistare testi sull'argomento...tnx
Formato cartaceo o elettronico?
Apegeo, mondadori informatica, mcgraw hill...
Se volete un bel testo sull'argomento io consiglio
Programmare vb 6 di Francesco Balena.
La soluzione è teoricamente elementare ma la realizzazione può non essere cosa breve.
Il problema si verifica perchè manca una linea d'ordine tra le modifiche dei client e manca un meccanismo di "feedback" sullo stato della base dati.
Per ordinare le modifiche alla base dati da parte dei client è sufficiente trasformarle in richieste di modifica. Lato client, i componenti aggiornano la base dati. Lato server, ogni aggiornamento è visto come una richiesta che viene infilata in una coda. Parallelamente, la coda delle richieste viene consumata semplicemente estraendo una richiesta ed eseguendola. Questo trasforma le richieste concorrenti di aggiornamento in un'unica sequenza di modifiche.
Per la politica di accodamento delle richieste, non è illogico pensare ad un primo ordinamento tra privilegi (le richieste di un amministratore sono eseguite prima delle richieste di un utente) seguito da un ordinamento temporale (le richieste di pari privilegio sono accodate in ordine di arrivo).
Il secondo gruppo di problemi è più delicato. Se più utenti hanno il diritto di modificare lo stesso dato devi necessariamente affrontare la possibilità di un conflitto tra due richieste di modifica. Considera questo caso:
A e B eseguono una query ed ottengono lo stato attuale del dato D. A e B inviano una richiesta di modifica di quel dato. Essendo la base dati unica, una delle due modifiche prevale sull'altra.
Per poter informare un client dell'interesse manifestato da un secondo client su un certo dato devi stabilire un protocollo che regoli le richieste di modifica alla base dati.
Uno potrebbe essere questo.
Il client invia al server una notifica di interesse sul dato D
Il server controlla se vi siano altri interessati al dato D. In caso affermativo, il server invia al client richiedente una notifica di attesa (qualcun altro vuole modificare quel dato) e registra il client tra i candidati all'accesso a D. In caso negativo il server registra il client richiedente come interessato attuale al dato D e invia allo stesso una notifica di accesso in modifica al dato.
Nel caso in cui riceva una notifica di accesso, il client invierà le modifiche da apportare. Il server modifica il dato, elimina la registrazione del client tra i richiedenti, notifica a tutti i candidati all'accesso l'intervento di una modifica e notifica al primo candidato all'accesso l'ammissione alla modifica.
Per prevenire blocchi a tempo indeterminato sui record devi anche introdurre un meccanismo di scadenza-rinnovo delle richieste di accesso (crash del client e gli altri stanno lì con un pugno di mosche in mano)
Questo dovrebbe permetterti di costruire un'applicazione in cui gli utenti possano essere informati sulla consistenza dei dati a cui hanno accesso.
[...]
Grazie. Andrebbe bene qualcosa di relativamente più semplice: mi basta che una volta che il file sul server è stato aperto da un client, gli altri lo trovino occupato e non riescano a scriverci sopra (e che quindi ricevano un messaggio di errore). L'inibizione deve essere sulla scrittura del file quando viene aperto da un altro client.
Altri consigli, anche su libri...righe di codice ecc ecc?
Grazie a tutti!
Ma non si era detto di non usare i db?
Ma l'applicazione di cui tu parli non richiede un'archituttura client-server?
Mi sembrerebbe molto più facile a questo punto utilizzare i db (anche se la tua idea mi piace)
L'architettura è client-server nel senso di "posizione dei file db".
Sui i vari client gira un programma che lavora su un database in formato testo. Il seguente database (nella realtà sono molti files di testo) è sull'hd di un computer sul quale gira anche un programma "generale" che interviene anche su altri database (sempre files di testo).
In realtà i programmi dei vari client sono addirittura diversi tra di loro....
Ma non si era detto di non usare i db?
Ma l'applicazione di cui tu parli non richiede un'archituttura client-server?
Mi sembrerebbe molto più facile a questo punto utilizzare i db (anche se la tua idea mi piace)
Nn ho capito a cosa ti riferisci...
Risolto con le funzioni di VB "Lock" e "Unlock". Purtroppo vanno inserite in ogni singola procedura. Abbiamo associato all'errore 70 (file, appunto, bloccato) una finestra con : "Il file è in uso". Cliccando su ok c'è un resume col quale il programma tenta nuovamente di scrivere: se il file non è in uso, bene. Altrimenti ancora errore 70.
Contro
1)certamente più fastidioso rispetto alla creazione di un protocollo di richiesta/attesa scrittura. E' l'operatore che deve "tentare". Non è un gravissimo problema perchè i client sono pochi e quindi sono situazioni che si verificano raramente.
2)è codice da inserire in ogni procedura di scrittura dati.
Pro
1) più economico e rapido da "progettare" e implementare
Perchè fai apparire la finestra ?!?!? A che ti serve ? Non la fare apparire e fai addormentare il programma per un tempo pari a 100ms e poi ricontrolla se puoi aprire il file... In questo modo eviti l'attesa attiva e limiti un po' la starvation...
In alternativa potresti creare un serverino TCP che gestisce la concorrenza sul file...se un processo ha bisogno di un file invia una richiesta, quando riceve il token inizia la gestione del file e comunica la terminazione dell'operazione quando ha finito...
Il serverino TCP è banale...quando legge una richiesta, se il token è disponibile lo assegna al richiedente, se non è disponibile mette le richieste in coda...quando legge la terminazione dell'operazione, assegna il token al prossimo in coda, se c'è...
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.