>>Generally speaking, yes. It's a good idea to wrap these attempts into some type of "try-catch", and maybe some retry loop.
>>
>>You might already know about this- it's a good idea also to view the entries in SYS.DM_TRAN_LOCKS. That's more for troubleshooting but it tells you any process ID that has a lock (shared or write) on any tables.
>>
>>While I'm not a fan of WITH (NOLOCK) if the initial query has ZERO risk of bringing back incomplete/uncommitted data, you could theoretically issue a WITH (NOLOCK) on the SELECT, and that would avoid instances of an UPDATE causing an issue. But again, you need to think carefully about that one.
>
>All my select commands all have the NOLOCK statement. Are you saying that with the NOLOCK statement that I should not have those issues? I remember this was the reason I implemented it. Before, I had this situation much more.

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

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.

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.

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.