Newsgroup: it.comp.lang.delphi
Titolo: Bloccare un record con IB6

E' possibile fare il lock di un record con IB6, magari come si fa con
Paradox ?

 Paradox ?
La risposta alla tua domanda non la so, ma ho una domanda per te: perchè ti
cimenti con i meccanismi di Locking?
Non ne ho affatto sentito parlar bene.
Ciao!
--
- Carlo -
c.b...@libero.it

 Non ne ho affatto sentito parlar bene.
??
Ciao,
-=SIMO=-

 Paradox ?
Se setti il livello di isolamento a repeatable read e fai una select del
record, lo lokki finchè non farai un rollback od un commit della
transazione.
Ciao,
-=SIMO=-

 transazione.
chesstoria, non lo sapevo...
per il momento non mi e' mai capitato di dover lokkare "di brutto",
pero' non si sa mai..
tnx
Alan Solo

 ??
Sinceramente non li ho mai utilizzati, sto solo riportando quanto detto da
altre persone.
Lo stesso Cantů, in un vecchio post suggerě a qualcuno di abbandonare tale
approccio ... personalmente ho studiato i meccanismi di Locking in un libro
prettamente teorico sui DB, e li erano illustrati ed era dedicato loro quasi
un intero capitolo! Sarei lieto se mi potessi dire le esperienze tue con
tale approccio.


 Ciao!
Ma scusa come fai a controllare l'accesso simultaneo ad un campo di
una tablella, che ad esempio deve essere incrementata di 1.
Due utenti, se accedono contemporaneamente in lettura, leggeranno lo
stesso valore ed il campo invece che di 2 si incrementerebbe solo di 1,
perche posterebbero entrambi lo stesso valore.
Come risolvere il problema se non "bloccando" l'accesso al secondo utente
in fase di lettura ????

 -=SIMO=-
Ma intendi con oggetti IBX o con quelli standard.
Sarebbe ottimo se funzionasse come Paradox
che lokka il record mettendolo in edit.
Grazie per la collaborazione.

 in fase di lettura ????
Adesso stai specificando la fase di lettura, prima non lo avevi fatto ...
Da : "Le Solite domande sul Client/Server" di Piero Bonanno su
Libero.Delphi.Database
1) Qual'e' il metodo migliore per bloccare un record in scrittura mentre
qualcun'altro lo sta modificando?
Risposta di Cantù :
Non farlo... e lasciare che avvenga un conflitto di aggiornamento.
La mia era solo una curiosità pechè pensavo tu facessi riferimento alla
scrittura.
Ciao! :)


 utente in fase di lettura ????
in questo caso sono piu' dalla parte di Carlo,
potresti usare anziche' le standard transazioni
readCommitted (leggi cio' che e' "committato" :P)
con DirtyRead (letture sporche),
sinceramente non ho mai affrontato approfonditamente
il problema, ma teoricamente dovrebbe andare...
Ciao,
Alan Solo

 ha scritto nel messaggio
news:pUOV5.8539$hk4.2...@news.infostrada.it...

Con tutti i RDBMS (e relativi oggetti x l'accesso) che supportano il livello
di isolamento REPEATABLE READ o superiore (Oracle, IB, Informix, SQLServer,
Sybase, ecc..). Non credo che i DB basati su file supportino questo livello
di isolamento (o addirittura i livelli di isolamento tout court..)
Ciao,
-=SIMO=-

 il problema, ma teoricamente dovrebbe andare...
In DIRTY READ le letture che effettui sono letture di dati teoricamente
modificati da transazioni non ancora committate (e che teoricamente
potrebbero essere successivamente annullate..) !!! In ambienti multiutente
un evento del genere è assolutamente una disgrazia e fonte di non pochi
guai...
Come livello minimo è consigliabile READ COMMITTED.
Ciao,
-=SIMO=-

 tale approccio.
Personalmente uso solo readonly (forwardonly) datasets ed action queries. In
questo caso (acceso diretto al motore, senza fronzoli..) i livelli di
isolamento sono indispensabili. In ogni caso i livelli di isolamento
permettono un controllo sul locking a livello di transazione, ovvero
proteggono la transazione nella sua interezza e la isolano da altre
transazioni concorrenti.
Naturalmente devi gestire il lock timeout ed eventualmente ritentare la
transazione (con un controllo sul numero massimo di tentativi, il tempo di
attesa tra un tentativo e l'altro e l'eventuale interazione con l'utente..).
Meglio attendere che ottenere (o peggio aggiornare) dati non veritieri..
Ciao,
-=SIMO=-

 che lokka il record mettendolo in edit.
Se devi lokkare solo in scrittura, usa  READ COMMITTED.
Ciao,
-=SIMO=-

 Meglio attendere che ottenere (o peggio aggiornare) dati non veritieri..
Su questo mi pare che non ci sia il minimo dubbio.


 di non pochi guai...
infatti, e' per questo che si chiamano DIRTY! ;)
io non ho fatto molte prove in mutiutenza,
ma se un utente legge un ID, lo generea aggiungendo 1,
la sua transazione e' ancora in limbo...
un altro utente contemporaneamente legge lo stesso ID,
che pero' e' l'ID vecchio, perche' il primo utente non ha fatto il
commit, e aggiunge 1...
ora, entrambi gli utenti committano.
... si troveranno gli id uguali, o sbaglio?
Ciao,
Alan Solo

 wrote in message
90b2jp$il2e$1...@ID-44131.news.dfncis.de...


> Infatti e' proprio cosi'. Ed e' un bel casino...
io non ho mai avuto problemi, e non avendoli avuti
non mi sono mai posto il problema del lokkaggio
il tuo problema mi sembra di capire e' quello di garantire
un id univoco e il metodo piu' sicuro (e semplice) e' usare
i generatori, questi infatti vengono gestiti dal motore
e tu te ne puoi altamente fregare (coma faccio io ;))
dal manuale:
"A generator is global to the database where it is declared.
Any transaction that activates the generator can use or update
the current sequence number. InterBase will not assign duplicate
generator values across transactions."
risposta definitiva: "fregatene, non blokkare niente"
(come dice Carlo e Cantu', ahemmm forse e' meglio
come dice Cantu'... e Carlo ;))
ps: lascia pure la proprieta' TransIsolation a ReadCommitted
(il piu' sicuro e quello di default, come ti suggerisce Simo,
il generatore genera cmq un id univoco)
Ciao, :)
Alan Solo