Hi Patric,
Yes. The solution is as you said.
I found it out the hard way. As I pointed out in another message
changes of this sort should have beein documented.
Thanks,
Yiorgos

>I have learned about the cause (see below) and the solution I am using is putting a tableupdate after my update in the scan so that the buffer is always empty and optimized. Fixing this will calm a lot of my users down about slow performance recently.
>
>-Patrick
>
>
>VFP8 doesn't Rushmore optimize SQL-UPDATE or SQL-DELETE if target table uses table buffering and the buffer is not empty. This change was made because previous VFP versions don't look into buffer if query is Rushmore optimized and do look into buffer if the query is not Rushmore optimized. This means that the same query potentially affects different amount of records depending on whether there is an index it can use. This issue was discovered very late in the product cycle and the safest way to fix it was to disable Rushmore optimization if there is a possibility of inconsistent result.
>
>Thanks,
>Aleksey.
>
>
>
>
>>It seems that I have the same problem. see Thread ID: 799905
>>Did you find any solution?
>>
>>
>>
>>>Has something changed in VFP8 that makes using the SQL UPDATE with optimistic table buffering slow unless a Tableupdate is performed after each update?