Wll, I guess I should have been more clear. The method I suggest is the way to go if some of the to be inserted values can only be acquired after having locked and requires a search that takes some time. For example, suppose you want a unique number that suits the need for a unique record key, but you don't want to use any of VFP's own functions for that, then this is the way to go. During the lock of record 0 you have all the time of the world to scan through the table in search of a key that conflicts nowhere. (Of course, all that time some other users may become frustrated because they cannot continue with their insert.)

>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() )