Newsgroup: it.comp.lang.visual-basic
Titolo: VB6 ADO e Access2000

Ciao a tutti,
vi sottopongo il mio problema:
Ho un DB Access 2000 al quale accedo tramite ADO 2.7. Essendo il DB in rete
ho bisogno di gestire l'accesso contemporaneo da più client mettendo dei
lock.
La procedura gestisce una tabella dei progressivi per alcune delle tabelle
esistenti, quindi quando si salva un nuovo record (es. in Tabella1) il campo
della tabella progressivi viene "lokkato" aumentando il progressivo e
successivamente salvato con l'update quando il salvataggio nella "Tabella1"
è andato a buon fine.
Il tutto sotto transazione per poter effettuare le dovute rollback e se il
record nella tabella progressivi dovesse essere già "lokkato" viene
effettuato un ciclo per attendere che si sblocchi (dopo 10 volte che va in
timeout esce e segnala che la risorsa è occupata).
Il problema sta nel fatto che ADO non scrive subito le modifiche nel DB
access, quindi in una modifica contemporanea il secondo utente rimane
correttamente "lokkato", ma quando si sblocca il record la lettura riporta
il vecchio valore.
Ho provato tutte le impostazioni possibili e immaginabili : da Jet
OLEDB:Transaction Commit Mode = 1 al RefreshCache di JRO come da KB di
Microsoft 
http://support.microsoft.com/default.aspx?scid=KB;EN-US;Q200300
 ,
ma non cambia nulla.
Qualcuno ha idea di come si possa fare?
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 Qualcuno ha idea di come si possa fare?
io, al tuo posto, invece di reinventare la ruota, userei un vero
database client-server.
-- 
ciao, hal

 database client-server.
maro', carthago delenda...
se catone ti incontrava, si sarebbe umiliato.
hal1961 a.c. il censore :)

 hal1961 a.c. il censore :)
pignolo ed efficiente, caso mai :P
-- 
ciao, hal

 ciao, hal
Beh, potendo lo farei volentieri ...
Sta di fatto che il problema č legato ad ADO, con DAO che č stato creato ad
HOC per Access il problema non sussiste. Mi chiedevo se mi manca qualche
impostazione particolare per farlo scrivere subito nel DB ...
Attualmente ho impostato :
Jet OLEDB:Flush Transaction Timeout = 5
Jet OLEDB:Implicit Commit Sync = True
Jet OLEDB:Max Locks Per File = 100000
Jet OLEDB:Max Buffer Size = 100
Jet OLEDB:Shared Async Delay = 0
Jet OLEDB:User Commit Sync = 0
In piů eseguo il tutto in transazione e alla fine lancio il
JRO.refreshCache.
Nessuno ha mai riscontrato lo stesso problema?


 lock.
Boh...
Questa cosa dei lock non l'ho mai capita, ma evidentemente è una mia
difficoltà...
Come fai a "scrivere" sul db? Generi un recordset o esegui dei comandi sql?
-- 
Salutoni
Sergio
..Nessun baol esiste.
Non sei mai esistito, Baol, se non nei nostri sogni.
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it


Tramite recordset.
Il lock viene impostato automaticamente dal db nel momento in cui cominci a
scrivere in un record. (In DAO veniva impostato sull'EDIT).
Impostando poi il parametro Jet OLEDB:Database Locking Mode=1 puoi creare il
lock solamente sul singolo record (non per tutte le versioni di Jet se non
erro) anzichč sulla pagina.
Il problema č tutto imputabile ad ADO che non scrive immediatamente le
modifiche nel DB quando viene rilasciato il lock (all'esecuzione del comando
"update").


 Tramite recordset.
Prova a vedere se utilizzando direttamente i comandi sql l'aggiornamento è
immediato...



In questo caso non saprei come gestire il lock e l'accesso contemporaneo di
più utenti : entrambi leggono come ultimo progressivo il valore 2, entrambi
aggiornano il progressivo a 3, entrambi proseguono nel salvataggio dei dati
impostando il valore 3.
Sicuramente andrà in chiave duplicata.
Ciao


 aggiornano il progressivo a 3
Mica tanto.
UPDATE TABELLA
SET VALORE=VALORE+1
WHERE CODICE='PIPPO'
AND VALORE=2
Poi testi il numero di righe modificate (@@ROWCOUNT in Sql-Server, vedi 
tu in Access).
Un esempio di questo concetto lo vedi benissimo quando studi la 
concorrenza in .Net, nei paragrafi che parlano dell'UpdateCommand del 
DataAdapter. Molti esempi fanno uso del TimeStamp, che in Access credo 
tu non abbia, ma il concetto è comunque quello di eseguire gli Update 
vincolandoli al fatto che non sia avvenuta alcuna modifica dalla 
lettura precedente.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.


Supponendo che l'aggiornamento sia istantaneo (non ho ancora provato,
cercherò di farlo comunque al più presto), mi chiedo cosa succede questa
UPDATE viene effettuata all'interno di una elaborazione più grande che viene
fatta tutta sotto transazione e che impiega una manciata di secondi per
andare a buon fine.
L'utente 2 non vedrebbe la modifica dell'utente 1 fino alla sua commit e
resterebbe fermo sul valore sbagliato nel caso lanci la stessa elaborazione
durante quella dell'utente 1...
Il lock invece dovrebbe essere visto anche sotto transazione se non erro.
Grazie
ciao


 durante quella dell'utente 1...
No.
L'utente2 non vedrebbe la sua Update girare fino al commit (o rollback) 
della transaction avviata da Utente1.
Quindi, comunque sia, se Utente1 esegue il Commit, l'Update di Utente2 
non avviene, o perchè va in timeout, o perchè il valore da modificare 
non è più il valore precedente. In ogni caso, non avresti il buon esito 
dell'Update, col risultato che Utente2 non proseguirebbe 
nell'inserimento della chiave nella tabella vera (che era il tuo 
problema).
Se invece Utente2 aspetta il commit di Utente1 che però ha bisogno a 
sua volta del commit di Utente2 perchè deve lavorare su qualcosa 
d'altro, è un discorso diverso, sarebbe un deadlock, ma non è il tema 
di questo thread.


 Alberto
Ho rigirato tutta la frittatona.
Ho provato ad aggiornare direttamente con una execute (mantenendo però
transazione e JRO.RefreshCache) e sembra che la scrittura delle informazioni
sia istantanea (per quanto ho potuto testare).
Detto ciò ho girato la gestione del lock che non è più fatta sul recordset,
ma direttamente dalla transazione e mi testo oltre che la commit andata a
buon fine anche il numero di record aggiornati.
Sembra funzionare!
Grazie mille per l'aiuto
Ciao
Peo
