>Ed thanks for your quick reply!
>
>I did not mention that other terminal also i accessing the dbf.
>This is with views and in the DE I'm using Optimistic table buffering.
>This terminals is not manipulating the dbf. only looking on the data (stock).
>Is this a source to the problem?

It shouldn't be, especially since you aren't changing the data at the other station.

>By the way I'm calling in for tonight in Norway its 2:20 AM.

have a good night!

>
>
>Best regards
>Per Simmersholm
>
>
>
>
>>>Hi Ed!
>>>
>>>Does this means that I dont have to think about RLOCK()??
>>>
>>
>>RLOCK() wouldn't be applicable to INSERT INTO; the alternatives are to use FLOCK() to acquire a lock on the whole table (the record doesn't exist, so there's no record to RLOCK()), use the file exclusively, or rely on the automatic locking of the header from INSERT INTO. If you need to lock the record you've just added after the INSERT, you needto issue an RLOCK().
>>
>>>
>>>Best regards
>>>
>>>Per Simmersholm
>>>
>>>>>Hi All!
>>>>>
>>>>>Is INSERT INTO only locking the new record if SET MULTILOCK OFF??
>>>>>
>>>>
>>>>INSERT INTO should be locking the table header; someone can have existing records locked, but only. In one person at a time can actually add a record to the table, so, like APPEND BLANK and APPEND FROM, VFP locks the header before it adds new records to the table, and releases the header when it's finished. The new records are not held locked once the table header is released. Once the INSERT INTO completes, the records added are not locked.
>>>>
>>>>>I have 2 terminals accessing the same table. I have some
>>>>>problemes with what is inserted into the table.
>>>>>I have a product number and name (variables) inserted into
>>>>>the table but it seems to me twice a week the number and name is
>>>>>wrong.
>>>>>First I write a label for a pallet, then I store the prod.nr and
>>>>>prod.name.
>>>>>I have 2 terminales operating on the same stock dbf inserting
>>>>>new records.
>>>>>
>>>>>Best regards
>>>>>Per Simmersholm