Newsgroup: it.comp.lang.visual-basic
Titolo: [?] V/s esperienze multiutenza...valgono + di 1000 messaggi

Ciao ragazzi,
io programmo da poco, e da poco frequento il V/s newsgroup...
ma le regole le conosco...
1)ho usato msdn
2)ho usato google
e di informazioni ne ho trovate a bizzeffe ma tutte molto personali...e
allora chiedo anche a Voi!!!
vorrei sapere come procedere:
Il mio problema è questo:
Ho sempre implementato le mie applicazioni ( con Ado o con connessioni, no
Dao) usando come base il db di Access...
ho provato ad usarlo in multiutenza su una LAN con 10 pc (il db su server)
ma le operazioni che effettuava erano piccole sciocchezze e quindi non dava
problemi.
Ora dovendo implementare un applicazione per terzi mi sono informato e un
tizio mi ha detto:
"Ma come gestisci la multiutenza, solo l'mdb non basta, non ti fidare del
Lockoptimistic e cose varie c'è tutto un modo per gestire la multiutenza che
devi imparare!!!"(Saranno le transazioni???)
Quindi vorrei sapere:
1)dato che Access può (e sottolineo può) dare problemi con multiutenza, da
che parte devo iniziare per studiare l'uso delle transazioni?
C'è qualke documento esaustivo che ne parla?
2)usando le transazioni per poche utenze( diciamo fino a 6) la struttura di
mdb va bene o anche usando le stesse conviene cambiare tipo di database?
Grazie come al solito...

 mdb va bene o anche usando le stesse conviene cambiare tipo di database?
Non uso transazioni e non me ne importa nulla se si solleva l'intero vecchio
continente.
Non le uso, vado benissimo cosě.
Perň blocco (col metodo che troverai ampiamente descritto cercando con
Google) quel che dev'essere bloccato. Nessun problema.


ti riferisci a lockoptimistic o pessimistic e all'uso del cursor ?

 ti riferisci a lockoptimistic o pessimistic e all'uso del cursor ?
No, non esattamente: Uso solo il lock ottimistico, mi riferivo al fatto di
"bloccare logicamente" (ovvero gestendolo con artifici interni) il record
sul quale devo fare operazioni importanti, per impedire agli altri di
accedervi finchè non ho finito.
Vedi qui, tutto il 3d e anche i link interni:
http://makeashorterlink.com/?C4A826283

 multiutenza che devi imparare!!!"(Saranno le transazioni???)
Access in multiutenza va benissimo, non è quello il problema.
Il problema di Access con molti client è legato all'aumento di probabilità
di crash di un client, con relativo potenziale danneggiamento del DB (spesso
recuperabile con un intervento di ripristino, a volte invece non
recuperabile).
Oltretutto, il backup di Access, nonchè l'indispensabile compattazione per
db con molte operazioni, deve essere eseguito in accesso esclusivo, quindi
occorre schedulare dei momenti della giornata in cui un servizio (che dovrai
fare) si occupa della manutenzione del db.
Sostanzialmente, io sconsiglio l'uso di Access per accessi da parte di più
client, perchè Access è esposto a problematiche di danneggiamento che altri
dbms riducono drasticamente (Sql-Server o MSDE, ad esempio).
Soprattutto se tu sarai chiamato a rispondere di eventuale perdita di dati,
questo è un aspetto di cui tenere conto.
Il discorso delle transazioni e del lock è fondamentale per la logica
dell'applicativo, per evitare cose assurde tipo aggiornamenti incongruenti
di due operatori sullo stesso dato, ma è ben gestito anche da Access.
Il punto però su cui riflettere è: in Access, sono i client stessi (o meglio
le librerie Jet che ciascuno di essi ha a bordo) a gestire la concorrenza,
sfruttando informazioni scritte sul file mdb e sul file ldb.
Se un client va in errore, è impossibilitato a completare determinate
operazioni, a liberare record o tabelle che stava tenendo bloccate, ecc..,
ed è una serie di regole interne del Jet che, prima o poi, consentiranno ad
un altro client di intervenire e risistemare la situazione.
Questo, però, finchè il client moribondo non abbia fatto danni seri sul db.
Con sistemi dbms server (Sql-Server, MSDE, MySql, Oracle, DB2, ...), tutti i
lock sono gestiti da un ente superiore, che è appunto il dbms, che se non
riceve risposta da un client si occupa di liberare le risorse bloccate, ed
impedisce che un client impazzito possa danneggiare il db.
Un'ultima considerazione: Access è un dbms basato sull'accesso diretto ai
file. Quindi, occorre concedere ai client il diritto di lettura e scrittura
sul file stesso.
Come caso limite, diciamo che se un utente, incazzato con la ditta, vuole
sostituire i dati con un mp3 rinominato in mdb, può farlo.
Oppure, può tranquillamente copiare il file mdb sul proprio hd, poi
portarselo a casa (il tool per individuare la password di un file di Access
è scaricabile da internet in due secondi).
Ciao
Alberto


Concordo in pieno con Alberto!