Wow, How did I miss that for all these years???

Thanks to both of you!

Rick
---------------------------------------------------------
>Jim got the answer, just to add take a looka at this taken from the help file
>
>SYS(2011) - Current Lock Status
>See Also
>FLOCK( ) | LOCK( ) | RLOCK( ) | SYS( ) Functions Overview
>Returns the record or table lock status for the current work area.
>
>SYS(2011)
>Return Values
>Character
>
>Remarks
>Unlike the FLOCK( ), LOCK( ), and RLOCK( ) functions, SYS(2011) doesn't attempt to lock the table or record.
>
>The character string returned by SYS(2011) is identical to the message displayed in the status bar (Exclusive, Record Unlocked, Record Locked ...).
>
>SYS(2011) returns Exclusive only at the workstation that opened the table exclusively, and Record Locked only at the workstation that applied the record lock.
>
>
>
>
>>I'm real sure I know the answer to this, but I hope I'm wrong.
>>
>>Is there any way to test a record to find out if it is NOT locked?
>>....without locking the record as a result/consequence of the test...
>>
>>In the past I've always tested to see if I could get a lock... like this...
>>

>>IF RLOCK()
>> *locked achieved
>>ELSE
>> *could not lock - implies that someone else has the record locked
>>ENDIF
>>

>>But what I need is to know if someone else has the lock...
>>I suppose I could do something like this...
>>

>>IF RLOCK()
>> *locked achieved
>> UNLOCK
>>ELSE
>> *could not lock - implies that someone else has the record locked
>>ENDIF
>>

>>...but that seems wrong and if the timing is just so, could leave me with the same problem I'm tryin to address...
>>
>>

>>The problem I'm trying to address is that I have a user who created a record
>>(the record was created with an Append Blank)
>>edited the record in one of my screens and clicked the OK button...
>>The Code in the OK button failed on a GATHER statement with the message
>>"Record is in use by another."
>>

>>How is that possible????
>>And more importantly... What can I do about it????
>>
>>TIA,
>>Rick Liebespach