Hi Ed,
Thanks for the update on the ISRLOCKED() function. This has now become a totally useless function (IMO). Why even bother to take the time to find out if I have the record locked, why not just attempt to lock it with RLOCK()? If it returns .T. , then I have the record locked; if .F., I don't and what's more important is I can't.

As for the other items you mentioned, yes it can be taxing on a network and I know anytime you put a function into a SQL statement, the optimization factor goes out the window 99 out of 100 times. But with small tables (< 5000) and a half-way decent network, this is negligible (IMO).

If you really wanted to tax the network:

select *, !rlock() as locked from mytable into cursor c_temp
unlock in mytable

>A big problem here is that isrlocked() only reflects if the local system holds >a lock on the record in question, it does not tell you if the record is >eligible to be locked by the local system. And since the lock status can >change over time, the availability of a lock at the time of query may not be >the availability of a lock at a later time. The SELECT is a snapshot; it does >not dynamically change the status of records selected, especially where the >value of a function would have to be continuously updated against each record >of mytable, and this is inherently not Rushmore-optimizable. It's be very >expensive in terms of system overhead,netowrk traffic and server load if this >were not the case...