• dvdwouwe 72544 (2/24/2011)


    In this case, you can use hints on the UPDATE statement but NOT NOLOCK or READUNCOMMITTED, that isn't allowed, this means that updating a row always use a writer lock, and the lifetime of a writer lock ends with the end of the enlisted transaction.

    Ummm... Of course. I did not realize that my comments suggested such an ignorant thing as UPDATE with(NOLOCK). I was just pointing out that NO locking Hints of any type whatsoever was mentioned and that is a solution to these sorts of problems that does work. You are correct in stating that once you start using this method, it must be used everywhere, but that's the key to using locking hints to resolve these issues.

    Can i ask what database you used that had locking hints in 1991?

    I thought this was not added until SQL92 in 1992, but 20 years is a long time.

    If you want that readers aren't blocked by the writers use the read-committed snapshot mode introduced in the yukon engine. Then you still can read all the values without blocking (for the ones that are updating and not committed, you will see the latest committed version)

    Sounds like you have another good topic for an article, I hope your write it. In my experiance this feature is not available in all SQL environments so we have never used it in production code.

    It seems you feel that I was reducing the value of your opinion by posting mine.

    Good luck with that.