Newsgroup: it.comp.lang.visual-basic
Titolo: JET, multiutenza e locking, voi come fate?

Ciao a tutti, scrivo perché ho bisogno di qualche parere sulla
progettazione di una applicazione multiutente che userà JET a 32 bit.
Il problema è quello del locking: questo è quello che ho pensato:
JET blocca pagine di 2Kb quindi un blocco pessimistico (il default per
JET: blocca da quando si legge il record a quando si esegue l'update)
non è accettabile perché bloccherebbe troppi record oltre a quello in
uso.
Quindi diventa necessario usare un blocco ottimistico (LockEdits =
False). In questo modo il record viene bloccato solo prima di
effettuare l'update, si scrive il record e si sblocca subito. In
questo modo i locks dovrebbero durare solo qualche istante.
Fin qui tutto bene, ma se per caso si tenta di eseguire l'update
contemporaneamente ad un altro utente che ha modificato un altro
record nella stessa pagina uno dei sue non riesce a bloccare.
Prima domanda: JET è abbastanza intelligente da riprovare un po' di
volte prima di causare un errore? Leggendo l'help mi sembra di si, ma
vorrei tanto sentirmelo dire da qualcuno che lo ha verificato sul
campo...
Se è così l'errore viene generato solo se il lock dura più del
normale, in questo caso non resta che chiedere cosa fare all'utente:
lasci perdere o insisti?
Questo dovrebbe risolvere il problema della gestione di dati
provenienti da una sola tabella.
Ora supponiamo di avere un archivio di fatture, o di un qualunque
archivio master-detail. Supponiamo che la fattura sia collegata ad
alcuni record in una tabella di primanota per le scadenze di
pagamento. Questo vuol dire che la variazione di una fattura potrebbe
causare la modifica di records in tre tabelle diverse. Come si può
fare per evitare che due utenti modifichino la stessa fattura?
Una possibilità è usare un lock pessimistico: ma questo vuol dire che
nessun altro potrà nemmeno vedere le altre fatture.
Se si usa un lock ottimistico è necessario memorizzare manualmente un
mucchio di dati (le righe e le scadenze) prima di permettere l'editing
e rileggerli tutti prima di scrivere le modifiche per vedere se
intanto qualcun altro ha modificato la stessa fattura.
Come vedete mi sembra un modo piuttosto laborioso.
In piccole installazioni potrebbe anche essere accettabile l'uso di un
lock pessimistico sulle fatture, tutto sommato di solito le fatture le
gestisce una sola persona.
A me però sarebbe piaciuto usare una sola tabella per tutti i
documenti master (bolle fatture ecc.) ed una sola tabella per tutti i
detail (righe bolle, righe fatture ecc). 
In fondo questi documenti hanno molto in comune, unificare le tabelle
renderebbe tutto più semplice e faciliterebbe l'aggiunta di un altro
documento in un secondo tempo (ad esempio le note di accredito).
A questo punto però un blocco pessimistico non bloccherebbe
verosimilmente solo le fatture, ma anche gli altri documenti, e questo
non è più accettabile.
Insomma, vi ho spiegato il mio problema e quello che ho pensato io. Mi
piacerebbe sentire qualche opinione al riguardo, se qualcuno ha già
realizzato progetti simili. In fondo questi sono problemi che
riguardano molti di noi e mi piacerebbe iniziare una discussione
costruttiva.
Grazie a tutti quelli che sono riusciti a leggere questo poema fino
alla fine e che vorranno dare un loro contributo.
Fulvio Senore.

alla fine e che vorranno dare un loro contributo.
Mah, con vb3 e access 2 io lavoravo in pessimistico utilizzando un
campo della tabella come Lock, ovvero edititavo, impostavo il lock a
true e poi updatavo, ovviamente prima di editare verifico che il lock
sia a falso. Quando avevo finito, mettevo il lock a false. Questo
pero' avevo ancora degli errori dovuti agli n^n bug di vb3, pero' era
accettabile. Ora devo fare un po' di prove con vb5.
Comunque per me quelli che hanno studiato access sono delle bestie,
come si fa a lockare 4k !!!!
---
 E.S.W.A.T.                 -= Guges-D =-                     E.S.W.A.T.
  \------/         Olympus, terzo terminale a destra           \------/ 
   \    /                (vicino a una 500-D)                   \    /
    \  /                 IACer & ANIBA D.O.C.                    \  /
     \/                Feccia di IAC (c) DDD '97                  \/
    MADM              Membro e Fondatore del MADM                MADM
                      Gran Sacerdote di MINNI !!!

=20
E se usassi una tabella per ogni tipo di documento facendo in modo che =
tutte le tabelle abbiano la stessa struttura ?
Prova a dare un'occiata alla mia Home-Page : =
http://www.geocities.com/SiliconValley/Vista/4041
 segui il link "Visual =
Basic-ORACLE" (ed Access) e prova a vedere il Cap 1 (Dimensioni del =
progetto) e il Cap 2 (Accesso al Data Base).
___________________________________________________
 Luca Minudel                      Conegliano (TV)
 telefono                              0438 412280
 e-mail                      
luca.m...@nline.it
 
http://www.geocities.com/SiliconValley/Vista/4041

campo...
Io ho tribolato parecchio per una applicazione che aveva delle
concorrenze piuttosto spinte su Access2, questionario alla fine dei
corsi (30 persone per 2 minuti lavorano in contemporanea sugli stessi
archivi e spesso sugli stessi records), su Access7 le cose vanno
decisamente meglio (dacche' ne so io non loccka anche gli indici e
quindi i lock sono molto meno pesanti).
Prima cosa al database devo dire che si tratta di un database
condiviso, manovra semplice (da menu) ma che ti toglie parecchi
problemi, tra i 20.000 settaggi dell' INI ce ne sono alcuni che
determinano inoltre il numero di tentativi (non chiedermi quali sono).
Io ho fatto come hai detto tu dei lock pessimistici ma ti devo dire la
verita' non c'e' stato verso di farli funzionare perfetti.
Se poi c'e' di mezzo un ODBC cambia anche tutto.
Insomma io ho risolto riprogettando in modo da limitare il numero dei
lock e oggi posso permettermi di gestire quello ottimistico (che con
Access7 sembra funzionare bene) in ogni caso ho una quantita' di dubbi
esagerata e aspetto il posting di messaggi che chiarifichino.
Purtrollo non ho piu' la possibilita' di fare dei test spinti.
Non rispondete pero' dicendo che ci sono con Access un paio di
procedure demo che gestiscono tali lock pessimistici correttamente
perche' sono le prime che saltano.

esagerata e aspetto il posting di messaggi che chiarifichino.
ehm, qualche codice da vedere ???


 False). In questo modo il record viene bloccato solo prima di
Io non utilizzo il bloccaggio dei record di VB-JET
ma utilizzo un mio DB sul server che tiene le azioni che fanno
i singoli utenti, gestendo correttamente questo DB le azioni
degli utenti li controlli tu e quindi se non devono fare qualche cosa
su un solo record non glielo permetti.
In questo modo puoi gestire il lock (logico ovviamente) addirittura sul
campo
come i migliori motori DB.