>>>>>>Thanks, Aleksey. In other words we need to use this setting for TABLEVALIDATE in our application if we want to be able to open the files.
>>>>>>
>>>>>Yes, you need to combine 4 with whatever setting you are using now, SET TABLEVALIDATE TO 4 will disable all validations and is equivalent to SET TABLEVALIDATE TO 0 in that sense.
>>>>
>>>>I think we're using VFP default now.
>>>>>
>>>>>
>>>>>>The records still may be locked, right? But only the records that were updated, not all the records in the file. Am I right here?
>>>>>>
>>>>>VFP may choose to lock the file rather than locking individual records, it all depends.
>>>>>
>>>>
>>>>Depends on what? We're inserting new records into several tables.
>>>
>>>One difference would be APPEND, which I understand locks the header for the duration of the append. I guess that would extend to the end of a transaction if transactions are involved.
>>
>>Jim,
>>the answer of Aleksey is ambiguous, because "lock the File" = FLOCK() allow the other process to
>>open the table, but every write operation is impossible until the END TRAN/ROLLBACK is done.
>>
>>But I don't believe that VFP does this,
>>I think that VFP do a RLOCK() for every written record
>>and a RLOCK(0) if some records it is append.
>>
>>In every way, Naomi has never clarified if the other process
>>that has to open the table has to write or no.
>
>The other process may need to write to the records, but not the same that were just inserted. But first is has to open some of the tables to view the data.


Hi Naomi.

The important thing to remember is that while buffereing is on nothing actually happens to your tables, thus the idea that the inserts were already over when the Transaction starts is incorrect. It's not until the TableUpdate starts that the table headers will be locked and the records appended. This means, as pointed out earlier (I think it was by Jim) that the table header will be locked when you update a table with new records and will remain locked until the End Transaction occurs. That is why transactions should always be quick. If you use a transaction it should always be Begin Transaction, TableUpdate & then End Transaction, it should never do any processing. All processing should be gotten out of the way up front. Also, the more records that you change in the batch the harder is will be for you to cope if any of the changes can't be saved. It's much better to only update one set of related records at a time. For example, if you had an order table and an order items table and you wanted to increase the price of each item by 10% and then place the price sum into the Order record you will find that handing things is must easier if you update one order per transaction since that way if the TableUpdate Fails you can just roll that one order back and try again.

Ian Simcock.