>Michel, this is something where utilizing SQL Profiler might help (or some other event-based approach to monitor what statements are occurring), to see what actually is going on.
>
>If only one update can happen, my guess is that there is some read process going on at the same time. And maybe that read process is taking a while to occur.
>
>If I do this...
>
>SELECT * FROM Member where Numero = @Numero
>
>And for whatever reason, that query takes a good while to run, that places a read (shared) lock on the row. That prevents other processes from issuing a write lock on the same row.
>
>You might want to check if there are any locked processes against the database. But either way.....for an UPDATE to occur,, SQL Server needs to be able to issue a write lock. And that is not possible if there are read locks on the row at the same time.

Thanks, I think this is related to this scenario.

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?