>>My user reported that an invoice could not be saved after it was edited. My reprocess was automatic and when they pressed ESC, they got the error - record is unlocked. I found that tableupdate of a view was the culprit and solved the problem by doing FLOCK of both the updateable tables before executing tableupdate. (the view update 2 base tables)
>>
>>The invoice with the same set of data runs well on local machine.
>>
>>What happen? Doesn't tableupdate know how to lock the base tables properly?
>>
>>Begin transaction
>>if flock('table1') and flock('table2')
>> if !tableupdate(1,.f.,'invoice_view')
>> unlock in table1
>> unlock in table2
>> */* Error Handling
>> RETURN
>> else
>> end transaction
>> endif
>>endif
>
>Yes, tableupdate() knows how and where to lock. Using FLOCK() on table you provide high probability of locking conflicts.

Without FLOCK on the above codes, it will fail on some invoices. With the FLOCK, there is no problem.

I am getting my user to test to see if forced tableupdate(1,.T.,'xxx') helps or not.