Hi!

It is ok to set the _VFP.AutoYield to .T. temporarily before some process and then set it back to .F. For example, set it to .T. before requery(), and then set back to .F. after requery() for view.

>If he sets autoyield to .t., then won't his activex (if any) stop functioning correctly? I had to set autoyield to .f. for the oncomm event to fire in the mscomm32 control. From the VFP help:
>
>The AutoYield property should be set to false (.F.) when a form contains an ActiveX control.
>
>I'm not clear on the autoyield property, but I HAD to set it to false for the oncomm event to fire.
>Tracy
>
>>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?
>>>>