Vlad,

I get this result when I run a 'naked' VFP 6.0, doing an Open from the Data Session window. I now have a healthy wariness of the odometer and status bar.

Thanks for the info. The best news for me is that VFP7 fixes this. In the meantime, I have a stupid computer trick to show my buddies.


>Hi!
>
>David is right. For me it looks too like internally VFP use DOEVENTS command to force odometer window and status bar updated. So in addition to mentioned commands try to use also SET STATUS BAR OFF. I recommend also to SET NOTIFY OFF. Or just update to VFP7 where DOEVENTS command works quickly (it is fixed now).
>
>Did you tried to set the _VFP.AutoYield to .T.? This have something to events processing too. I guess if it will be set to .T., VFP will not cal DOEVENTS command internally, and as a result will work more quickly during query running.
>
>If you still have no luck to fix the problem using above suggestions, you can try the view with FetchAsNeeded option. In such mode view is opened with first 100 records and then you can manually force downloading of the rest records in the loop, displaying the progress by using your own form. This might require some programming though.
>
>Hope this helps.
>
>
>>SET TALK ON/OFF, SET ESCAPE ON/OFF have no effect on the phenomenon, a moving mouse speeds up the query.
>>
>>The CONNECTION is ASYNC, if that is relevant.
>>
>>This is definitely one of the craziest things I have seen.
>>
>>>Alan,
>>>
>>>This might be related to the reason the fastdoevents article over on my website works.
>>>
>>>Does the query run fast without mouse motion if you have SET TALK OFF?
>>>