>That is correct, WITH NOLOCK avoids issuing a shared read lock on the rows.

Thanks

>So if all your SELECT statements against the table are truly using WITH NOLOCK, then you have a different issue. Either two updates are somehow occurring, or you have some other process going on. Again, using SYS.DM_TRAN_LOCKS can help you troubleshoot.

The two updates might be the reason. This login sequence triggers about 5 to 6 hits. Each of those will update the last time stamp to the user record. That is probably the reason.

>I hate to give a general suggestion to do a google search, but if you search on SYS.DM_TRAN_LOCKS and maybe a few keywords that are similar to your situation, you'll see different approaches that people have taken for different situations.

Ok

>But again, WITH NOLOCK means there's no shared lock being placed on the row - so those queries are not the culprit. It would have to be something else.

Thanks