Discussion :

[dymezac]

Bonjour,

Je me demandais si les requêtes SELECT qu'on ne met dans aucune transaction respectent bien les verrous posés par les autres transactions en cours (lectures propres)

Si oui, on pourrait dire qu'ils sont en "Read Commited"..

Et le seul intérêt de mettre des SELECT dans des transactions serait dans des transactions Read.UnCommited pour avoir des lectures sales "dirty reads".

Donc finalement autant ne jamais mettre de SELECT dans des transactions, ce qui permettrait de réduire au minimum les transactions (si ce sont des lectures propres qu'on veut)..

Je suis en train de chercher sur la msdn mais je ne trouve pas vraiment ma réponse.
http://msdn2.microsoft.com/fr-fr/library/ms190612.aspx

[SQLpro]

Par défaut SQL Server fonctionne au niveau d'isolation READ COMMITTED.

Toute requête est une transaction : un simple SELECT, un ALTER sont donc des transactions implicites. Lorsque vous posez un BEGIn TRAN vous faites une transaction explicite.

A +

[dymezac]

Merci SqlPro,

effectivement, je viens juste de lire l'intégralité du chapitre sur les transactions de la msdn (je le conseille vivement).. Je comprends mieux.

Comme sql server est en autocommit dans ce cas là, et que c'est read.commited par défaut, le select va respecter les verrous.

Par contre, il y a aussi un mode "implicite" dans sql server qu'on peut activer (désactivé par défaut), qui est encore un peu différent du autocommit, car on ne fait jamais de begin transaction, mais seulement des rollback ou des commit. Et juste derrière se crée une nouvelle transaction automatiquement. Le rollback ou le commit ne se fait plus sur une seule instruction comme en autocommit mais sur toutes les instructions jusqu'au précédent commit ou rollback.

en tout cas, merci SqlPro
vous m'avez beaucoup aidé sur différentes questions depuis que je viens sur ce forum. je met en résolu.