Well, then, it appears that SET STATUS would solve the problem. David?

Charlie- I don't personalyy use RLOCK for anything except when I need transactional results, like in a NewID() routine that gets a unique key for a table.

But how would RLOCK() ensure that the table header could be locked? What David was experincing was the locking of a table header that occurs when a record is inserted, or when a command that has whole or partial scope on the table is being executed (DELETE FOR, REPLACE FOR, etc).

Issuing an RLOCK would ensure that the current record could be locked, but seems to me to be of no help when inserting a new record...



>Erik,
>Help says: Visual FoxPro displays the "Waiting for lock ... " system message only if SET STATUS is set to ON.
>So I assume if you SET STATUS OFF, no system message.
>
>But what I was saying is to not use the automatic locking at all, but do it manually. If I RLOCK(0), and it returns .T., I insert, if it returns .F., I wait some random milliseconds, and attempt RLOCK(0) again. There's no problem with Waiting for lock then, is there?
>
>>this is indeed a different way about it, but doesn't get around the root of the problem: when VFP tries to lock a record, it usees the SET REPROCESS setting, and if it is anything but 1, will keep attempting to lock the record, depending on the setting. During these successive attempts, VFp gives the user a message "Attempting to lock..." and this qualifies as UI, a no no for an In-Proc server.
>>
>>