>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.