>But ISRLOCK(), as you stated, doesn't tell you whether you can actually get a lock on the record because it doesn't take into acount other people's locks.
>
>As for locking an already locked record, I guess it could save me .001 seconds or less. Not a lot in the great scheme of things unless we are talking about 500 records or more.
>

What about the situation where you try to get a lock and fail on the first attempt - reprocess could tieyou up a while...

>>Two issues - first, it's very fast relative to attempting RLOCK(), and it >doesn't acquire the. If you're relying on explicit rather than implicit >(automatic) locking, knowing the lock status is advantageous so that you >attempt to acquire the lock before making changes in row-buffered tables.