Disagree. I do not see a reason to use a lock of record 0. You are messing with something that VFP is designed to manage itself.

INSERT - SQL automatically locks the table header during execution. That means no add or delete actions can take place, as that would require updating the header record. Existing records can be changed. Append blank does the same thing, locks the table header.

Two append blank's at the same time can theoretically throw an access error, but they would not overwrite each other.

I have seen your problem several times over the decades, and each time it turned out to be a lan problem, a flaky NIC.

>>Hi all,
>>
>>I'm having a problem with an application sometimes confusing 2 records in a table. happens about once a week. Anyway I'm going over the code and I use scatter...append blank...gather in some places. I'm wondering if I change this to an insert command does the insert command automatically lock either the table or record while inserting. I'm trying to find out online but nothing explicit is popping up. It is VFP code and a VFP table.
>
>I guess VFP indeed locks prior to inserting a new record. Not the entire table, but 'record 0', which is a virtual recordnumber, also called the headerrecord. And after the insert it is released for use by others who want to insert. If an insert requires a value that must be unique - let's say a unique identifier - then it's wise to lock record 0 by hand beforehand.
>
>

*	Lock the header before inserting a new record.
>*	And have some patience because someone else may be trying an insert at the same time.
>do while not rlock( '0', alias() )
>enddo
>
>* Create the unique value(s) here, e.g. a unique record identifier.
>* Do your insert here.
>
>*	Unlock the header record.
>unlock record 0 in ( alias() )