Newsgroup: it.comp.software.database
Titolo: Un aiuto per capire i lock sui database SQL

Salve, non ho mai scritto su questo ng ma avrei bisogno, una volta per
tutte, che qualcuno mi spiegasse come si possono usare i lock sui database
SQL. Vi descrivo subito lo scenario che ho in mente:
 - Un database SQL (es. MySQL).
 - Una tabella contenente una semplice anagrafica articoli (ogni record e'
un articolo).
Supponiamo che io abbia realizzato un programma (in qualunque linguaggio)
che seleziona un record con una query SELECT.... e visualizza tutti i dati
dell'articolo in una finestra a video. L'utente li puo' modificare a
piacere e con un tasto di conferma li riscrive sulla tabella con una query
di UPDATE....
Il problema e' questo (che non ho ancora risolto). Come posso fare per
bloccare l'accesso a questo solo record da parte di altri utenti ??????
L' utente che modifica i dati sulla maschera ci puo' mettere anche dei
minuti quindi tra la SELECT e la UPDATE ci passa del tempo. Se
qualcun'altro facesse nel frattempo la stessa cosa ???
Un aiuto di concetto, per favore !
Andrea
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 bloccare l'accesso a questo solo record da parte di altri utenti ??????
Risposta breve: non puoi.
Risposta lunga: ogni database implementa meccanismi di concorrenza come
cavolo gli pare. Esistono due "scuole" di pensiero: "alla Microsoft" e
"alla Oracle". Scuola "alla Microsoft": ogni volta che fai una select
*tutti* i record interessati acquisiscono un Read Lock che impedisce a
chiunque di acquisire un Edit Lock. Cio' significa che nessuno dei
record puo' essere modificato ma ogni record puo' essere letto. Quando
il recordset viene distrutto il Read Lock viene rilasciato. Ovviamente,
se acquisisci un Edit Lock, nessun Read Lock puo' essere ottenuto. Il che
significa che nessun'altro utente puo' leggere i record finche' non hai
finito di modificarli.
Scuole "alla Oracle": nessun lock viene attivato sui record, quando vai
in modifica il database utilizza il log delle transazioni per "ricostruire"
il valore dei record modificati ma non ancora confermati, in modo che
chiunque lo chieda veda il valore *prima* che tu entrassi in fase di
modifica.
Vedi la documentazione del tuo database per come viene implementata la
concorrenza.
Davide

Una precisazione:
Come al solito Microsoft contro tutti?
Voglio dire, Interbase e Firebird, per esempio, mi sembra che adottino il 
modello "Oracle";
E tutti gli altri?
Sarebbe interessante conoscere un po' di casistica.
Grazie.
Michele Giordano

 Come al solito Microsoft contro tutti?
In ADO di default è cosi ma puoi scegliere anche una politca alla Oracle,
questo lo fai con il comande LockEdit.
MAX

 E tutti gli altri?
Non so come si comportino le nuove versioni di Sybase, credo che
DB2 abbia un funzionamento simile (qualcuno puo' dare qualche
indicazione in piu' ?)
Ciao,
-- 
Gianluca Hotz
Backoffice MVP (SQL Server) MCP SQL Server and MCP Windows
Vice-President of the Italian User Group for SQL Server
Founding Member of the Italian User Group for .NET
http://www.ghotz.com
http://www.ugiss.org

 wrote in message 
news:7dKH9.21635$t_1.1...@tornado.fastwebnet.it...

Attenzione perche' ADO e' generalizzato, ma deve sottostare
alle regole dell'RDBMS a cui si connette.
Il livello di isolamento offerto da Oracle non e' possibile
con SQL Server, neanche tramite ADO.
Quello che si puo' ottenere e' un livello di isolamento
transazionale piu' basso (il READ UNCOMMITED) che permette
di leggere i dati modificati ma non ancora confermati
(ben diverso da quello che permette di fare Oracle)
oppure un cursore che segue le regole della concorrenza
ottimistica (di fatto non viene mantenuto nessun lock
ed in fase di conferma delle modifiche possono avvenire
conflitti).


 di leggere i dati modificati ma non ancora confermati
E si...
Grazie per la info...
MAX