>I wrote a routine to 'lock' a record, which does not actually do a RLOCK, but REPLACE LOCKED_BY WITH USER_NAME, (but only if it is empty). that way you can 'unlock' a record by blanking out that field, and see who and when a record is locked. It does require a bunch of code to simulate the locking functionally of RLOCK, but the payoff's may be worth it. You could also do the RLOCK at this time, the advantage being that if the machine is turned off or crashes, the lock goes away.
>
>Carl

I would be interested in knowing how the RLOCK() is used to clear the locks. I've worked with a few systems (FPD,VFP, Pick Basic, etc) that utilize similiar "soft" locking techniques and I often find myself spending more time clearing these locks because of machine reboots, code crashing, or developers not adhering to established standards (ie. not using the modularized locking procedures, or not adding the extra field(s) necessary to track the locks).

If find the use of optimistic table/row buffering in VFP has yielded the best results in the systems I have written (50-200 users). Even if somebody does crash there are utilities for NT and Netware which will allow you to determine who has locks on tables (ie. RCONSOLE,SLOCK, or the FoxPro add-on libarary, GPLIB, for Netware and I often just use the Server Manager for NT).