Hi Nadya

I have to say, proceed very carefully!!! Changing the index expressions in a table will likely cause changes in other areas! Changing the query to match the existing indexes would be safer. Don't forget to restart the machine after such a change to ensure the better performance is not caused by caching.

>Mike,
>
>Disregard my other message. I started to look deep into this problem and found very nasty index expressions in some of the tables involved in the search. Once I fixed one of the tables, the search went instantenious. So I would not need to stop requery and do not have to change anything in the current implementation of the form.
>
>>Hi Nadya
>>
>>>Hi everybody,
>>>
>>>I have a local p-view with lots of parameters. It is created by joining 7 different tables and it has long time to requery(). Is there a way to stop requery() by hitting ESC?
>>>
>>>Thanks a lot in advance.
>>
>>I provided a feature like this to Drew Speedie who promptly made it part of Visual MaxFrame Professional. The basics of it are ...
>>
>>Add support for Error 1839 to your main errorhandler routine. That's the error you get when you escape from a query.
>>
>>*Remember the current SET ESCAPE and ON ESCAPE settings.
>>SET ESCAPE ON
>>LOCAL m.llQueryStopped
>>m.llQueryStopped = .F.
>>ON ESCAPE m.llQueryStopped = .T.
>>REQUERY()
>>*Restore the previous SET ESCAPE and ON ESCAPE settings.
>>
>>If the user hits escape, the error handler routine will do whatever you want with error 1839. llQueryStopped will be .T. so you can decide what to do. What's really cool about this, is that if there was data in that cursor before the requery, that data will still be there after the ESCAPE!
>>
>>Good luck!