Newsgroup: it.comp.lang.visual-basic
Titolo: SQL SERVER AAARRRGGGHHH

sono sull'orlo di una crisi di nervi.....
sto sperimentando i locks sulle tabelle e non riesco a fare alcun passo
avanti .
questo è il mio recordset:
    Set grstLock = CreateObject("ADODB.Recordset")
    grstLock.CursorLocation = adUseServer
    grstLock.CursorType = adOpenKeyset
    grstLock.LockType = adLockPessimistic
dunque il problema è che anche se riesco a loccare il record non riesco a
recuperare l'errore nel momento in cui un altro utente si appresta a
modificare lo stesso record e questo perchè SQL SERVER restituisce un
generico errore di TIMEOUT EXPIRED e lo stesso number..sia che il record è
loccato sia che stacco il cavetto di rete e la connessione salta!!!
c'è qualcuno là fuori che può aiutarmi????

 ha scritto nel messaggio
news:995adi$25mu$1...@stargate1.inet.it...

Se non ricordo male, ho letto da qualche parte che il modo migliore di
gestire i recordset pessimistici è quello di utilizzare gli eventi associati
al recordset.
A quel punto ogni aggiornamento viene notificato con eventi, restituendo
così anche i codici corretti di errore.
Per inciso ...
tutti coloro che si sono cimentati nella gestione delle concorrenze di
accesso hanno quasi subito abbandonato l'idea di utilizzare "solamente" gli
strumenti messi a disposizione di ADO.
Alla fine il metodo + sicuro è quello della creazione di tabelle di lock ..
ma la cosa aumenta notevolmente la scrittura di codice.
Saluti

 generico errore di TIMEOUT EXPIRED
    credo che non essita un errore per il blocco, semplicemente un utente
non puň vedere il record e/o viene messo in attesa da SQL e processato
successivamente la sua richiesta.
Credo inoltre, come da doc. Oracle, che il blocco impedisca la scrittura, ma
consenta la lettura del record.
Verifico e poi ti dico se trovo qualcosa di piů utile
Ciao
Massimiliano

 wrote in message dKyt6.52$lT1....@news2.tin.it...


vuoto...ma nulla mi sembra adeguato ed efficace
Se ne era discusso qualche tempo fa su questo ng e, mi si corregga se ho frainteso,
era emerso che, sia per la oggettiva complessita' della cosa sia per ragioni di prestazioni
(quanto tempo puo' rimanere bloccato il record ?) sono state adottate diverse soluzioni
"manuali".
Una soluzione, che sto adottando attualmente in un progetto intranet, prevede, fra l' altro,
la presenza di un campo numerico in ogni tabella di cui si intende gestire il "lock".
Ogni volta che si legge il record, si prende nota del valore in tale campo, che per comodita'
potremmo chiamare TICKET, e non si blocca nulla.
Nel frattempo altri utenti si connettono e possono leggere il record, ricevendo tutti lo
stesso ticket.
Il primo utente che fa una modifica, incrementa anche il valore del ticket.
Se un successivo utente tenta una modifica a sua volta, confronta il valore del proprio
ticket con quello presente in quel momento sul record (una banale condizione WHERE)
ed esegue la modifica _solamente_ se il proprio ticket e' ancora uguale a quello scritto nel db.
Siccome era stato incrementato precedentemente da un altro, viene generato un errore, 
avvertendo che il record e' stato modificato nel frattempo da un altro utente e quindi
viene ricaricato con i valori aggiornati.
In questo modo non si impegnano risorse piu' di tanto sul server e si evitano modifiche,
anche con conseguenze serie per l' attivita' dell' utente, in base ad informazioni errate.
ciao, hal