>Mike-
>
>>>IIRC, all you have to do is SET ESCAPE ON, then when asked if you want to cancel, say no.
>>
>>There would have to be no error handler in effect, so that's not good. But beyond that you get Cancel, Suspend, Ignore. Ignore seems to continue at the next line, without returning records, rather than continuing with the query.
>
>So it seems. I should have checked it before posting.
>
>>>Updated: Also, IIRC, there can be quite a bit of lag time between the time the user presses escape and the app responds. I don't recall at all how it compares to using one's own SET ESCAPE routine.
>>
>>There seems to be no difference in the time lag with one's own routine or without.
>
>Agreed. It's the same difference. My client who's had complex, long queries, and I visited this issue a couple years ago and we couldn't settle on any satisfactory solution, either.

This is a little different angle, but what I do where I know the user could be bringing an "over abundance" of records back from the server is do a count first. Basically, I create a new SQL string that replaces everything between the "SELECT" and the "FROM" with a COUNT(*) and run that through SQLEXEC. I give them a message that they are about to retrieve X number of records and ask them if they want to continue. In the case of a local or remote view, I can just get the SQL using DBGETPROP("MyView","VIEW","SQL").