>>To all:
>>The solution to the problem is that a TableUpdate must be
>>issued after each Update in the loop.
>>The problem appears not only with the SQL Update command but
>>also wilt SQl Delete etc.
>>In my case the solution was:
>>
>>Scan
>> M_ CODE= temp_curs.Code
>> Update invhed Set katpel= m_sys WHERE invhed.Code=M_CODE
>> If ! Tableupdate(0, .T., "INVHED")
>> * message code
>> endif
>>Endscan
>>
>>In general one must Tableupdate the table each time a record changes
>>or appended.
>>This is a major change from VFP7 to VFP8, and it should
>>have been documented from the very beginnig.
>>Practically I must review and change a lot in my code in order
>>to move from 7to8.
>>
>>Yiorgos
>
>
>Yiorgos,
>
>Could you confirm that performance degradation was not related to TABLEUPDATE, but to SQL-UPDATE called in the scan loop?
>Could you please do it on both threads so people will know where the real problem is.
>
>Thank you,
>Aleksey.
>
>P.S. You can simply switch to row buffering to avoid explicit TABLEUPDATE calls in the scan loop.

Aleksey,

Sorry for the delay in my reply. I was away from office for a week.

The delay was related SQL-UPDATE. Before I use the TABLEUPDATE command in the loop, I put a WAIT WINDOW command in the scan loop and I found out that
the major delay was in second pass in the loop (according to your explanation, in the first pass the buffer was empty and therefore no delay, in the second pass the buffer was not empty and the delay problem appears).
As I said in my previous messages the problem was solved by using the TABLEUPDATE in the loop.

By the way, how explicit TABLEUPDATE calls can be avoided by switching to
row buffering? Do you mean that the TABLEUPDATE calls are not needed in
the scan loop?

Thanks,
Yiorgos