GSquared (3/27/2009)
Nolock doesn't really do anything to updates at all. Won't do what you need.For example, user A takes a look at row 3 of table X. Meanwhile, process B updates that row, but user A never sees the update, because of nolock and such. So user A updates the row, overwriting what process B did. Now, is that row of data correct? Process B's update is gone, as if it had never been done, and user A may have wanted a different update than the one he did, if he knew the data was being changed by process B. It can make a big mess.
Thanks for the response.
And yes, i understand what you're saying.
But my case is little different. There would be a dirty read but it doesn't matter.
Say User U updates columns a,b& c of table T, the backend process P updates the column d of the same table T.
Column d makes no sense to the user(say it is for some auditing purpose), it is not shown to the user, nobody other than the process updates it.
In this case, you see a deadlock here, right ?
As i said, i tried a nolock for selects and rowlock for updates.
here is what i did :
1) user reads a row <----- nolock here
2) user updates the row <----- rowlock here
3) backend process updates the same row <----- rowlock here
This still did not resolve the issue completely. Maybe i am not doing it the right way.
Can someone help pls ?
Thanks again.