Re: Why a DELETE transaction running in read-uncomitted is acquiri

What I said was correct but it would be good to have more info and maybe see the actual query. You can have parts of the Delete statement run in uncommitted isolation mode such as joining on other tables to find the rows etc. But the row itself must be locked before it can be changed regardless of the isolation level.


--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"C elek" <Celek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message news:BFB67BA6-93DC-4CF2-949A-A93EE9A258FE@xxxxxxxxxxxxxxxx
Andrew that is what I thought, yet, the deadlock trace shows me the opposite
:( I guess I must trust the book and what you say right ? Which means it
cannot run in uncommitted even if the trace says so, correct ?

"Andrew J. Kelly" wrote:

A DELETE never happens in Read-Uncommited mode regardless of what hint you
may tried to use. Any modifications MUST take some sort of lock.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"C elek" <C elek@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F39FABDC-857D-4E2E-980B-F2E1C7E553D4@xxxxxxxxxxxxxxxx
>I am having trouble to conceptually understand this. COuld someone point >me
> to the RTFM or link ?



.

Relevant Pages