You're either going to have to limit the record set to something much smaller or not use a grid. Using a SELECT that's implemented by VFP as a filter won't help because you'll still be using SET FILTER with a grid which is not optimizable. I'm afraid there's no other way around your problem. You could use a BROWSE instead of a grid. It's obviously less flexible but it will allow you to use SET FILTER with rushmore.

>Josh,
>
>>Your choices are really to either use a parameterized view or SELECT records into a cursor.
>
>Using parametrized view or cursor causes same hangup as set filter+grid!
>My users can build itself queries. If they create a query returning
>200000 records, both parametrized view and select into cursor
>will copy ALL data to local disk before returning the query !!!
>This takes VERY long time and requires too many local disk space.
>
>How I can use your solution in this case?
>
>I'm intrested, will the phantom local view (a view which is
>implemented by foxpro as filter) + grid enable grid to use
>rushmore? This may be the only (very specific) case where
>index on deleted() may cause improved perfomance since this
>allows foxpro to create phantom local view and grid to use it!