>
>A user logs in from the main page, this generates the interface (multiple hits from that user are sent to the server to load the main interface, the toolbar, the left side, the map view, the first message of the map view and the right side). Those would issue selects to get that user record. In each of them, the tracker logs the last hit of that user. So, each of those hits are done simultaneously, each selecting the user record and each updating the user record. In the thousands of times this might be executed in a single day, I guess I would have to do as suggested, thus to trap the error and retry. So, I can retry about 5 times at interval of 0.25 second, in case such situation occurs. I have implemented that elsewhere about reading a file from the server, where at the same time an update of that file might occur. With the retry, this has eliminated the situation. This is very rare. But, when it happens, the retry takes care of it. Is this pretty much how you would resolve that one here?

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.