Newsgroup: it.comp.software.database
Titolo: SQL (NOLOCK)!

Grazie innanzi tutto.
Volevo sapere se è possibile settare l'opzione NOLOCK anzichè a livello
di query sulla clausola FROM, su tutto il database e per tutte le
tabelle.
La ragione della mia richiesta è dovuta al fatto che:
avendo sottovalutato i problemi causati dal begin trans, abbiamo una
serie innumerevole di query con SELECT che vanno in errore a causa del
blocco sulla tabella che in quel momento è stata interessata ad esempio
da un update su cui non è ancora stato dato il commit.
Per risolvere il problema dovremmo modificare centinaia di query e a
proposito mi sono chiesto se non fosse possibile settare questa opzione
a livello di db. Sull'help non ho trovato nulla.
grazie ancora! Nicola
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 da un update su cui non č ancora stato dato il commit.
oltretutto non dovrebbe andare in errore ma solo in attesa, salvo se
ci sono dei deadlocks (ma questa dovrebbe essere una situazione molto
rara ed in genere causata da errori nell'applicativo)
Greetings,
Alessandro Trebbi
Pesaro, Italy
http://www.b3soft.com

 select
Questo è valido x oracle, non per altri db.
ciao

 
Cerca nella documentazione del tuo database usando ISOLATION LEVEL come 
keywords.
Ho la vaga impressione che quello che cerchi te sia il seguente comando:
"SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED".
Comunque, non è buona pratica permettere delle dirty reads. Se la tua 
applicazione funziona come l'hai descritta, IMHO andrebbe 
reingegnerizzata...
HTH, bye!
 
-- 
Fabrizio "Hermooz" Ermini

 wrote in message
news:7039407d7850c3bedb7...@mygate.mailgate.org...

Ciao Nicola,
non esiste la possibilita' di impostare qualche cosa di simile
alla direttiva NOLOCK a livello di database, e ci sono dei motivi
molto validi.
La direttiva NOLOCK equivale ad operare al livello di isolamento
transazionale READ UNCOMMITTED (detto anche "dirty reads").
Operando con questo livello di isolamento significa poter
leggere modifiche non ancora confermate.
Ad esempio: la connessione C1 apre una transazione, modifica
la quantita' a magazzino del prodotto P1 da 10 a 100,
la connessione C2 legge la quantita a magazzino del prodotto P1
ed emette un ordine per 50 unita', la connessione C2 conferma
la transazione, la connessione C1 annulla le sue modifiche
(esegue un rollback della transazione). Il risultato e' che
la connessione C2 ha letto una quantita' che in realta' non
e' mai esistita e, nell'esempio, ha dato origine ad una
ulteriore operazione che non doveva essere eseguita.
Il livello di isolamento transazionale predefinito per
SQL Server e' il READ COMMITED che non permette la lettura
di modifiche non ancora confermate.
Questo livello di isolamento, per specifiche ANSI, puo' essere
implementato in due modi: bloccando la connessione che sta
richiedendo il dato oppure fornendole la versione precedente
la modifica (ben differente dal fare un dirty read!)
Senza entrare nel merito di quale dei due approcci abbia piu'
senso (dipende dalla transazione), SQL Server implementa la
prima modalita': blocca la seconda connessione.
E' possibile modificare il livello di isolamento transazionale a
livello di connessione tramite il comando SET TRANSACTION ISOLATION
LEVEL (oppure direttamente con la proprieta' dell'oggetto Connection
di ADO).
Detto questo ti sconsiglio assolutamente di impostarlo, cosi'
come ti sconsiglio eventualmente di mettere NOLOCK a mano
in tutte le query, risolveresti i problemi di accesso concorrente
ma ad un prezzo ben piu' alto.
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