Paul, TTBOMK, there is no way to identify the user that has locked a table and left for home or gone fishing <g>. LIST TABLE tells you whether the lock is an edit, row, cursor, local or remote lock. Edit, row, and cursor locks are set by R:BASE as part of its internal concurrency control. A LOCAL LOCK is set by a SET LOCK command issued at the workstation that issued the LIST TABLE command. And a REMOTE LOCK is set by a command that obtains a table lock and is issued from a workstation other than the workstation that issued the LIST TABLE command. When it becomes a constant issue, and if users leave their database connected, then, I would recommend to use the ENHANCED SET TIMEOUT option using TGRB2000 (version 6.5++). For more details, check out the latest, greatest and up-to-date http://www.Rsyntax.com Have Fun! Very Best Regards, Razzak. At 01:31 PM 7/18/2001 -0700, Paul Bordine wrote: >Occasionally a cursor lock will be left on a >table during the day, and it is impossible to >require all users to simultaneously disconnect >from the production database to remove it. > >Is there a way to identify the user that has >locked a table? ===================================-============================ R:BASE Developers's Conference: http://www.rbase.com/conference Official R:BASE List Server: mailto:[EMAIL PROTECTED] RBTI Events/Training: http://www.rbase2000.com/events R:DCC Members: http://www.rbase2000.com/rdcc ================================================================ R:BASE, Oterro & R:Tango are registered trademarks of RBTI. ==================================-=============================
