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!

>The problem with grids and SET FILTER is that for some reason the SET FILTER command won't use rushmore in a grid. Using a DELETED() tag will improve the performance of any command that's rushmore optimizable if SET DELETED is on or DELETED() is used to filter the records. The problem is that SET FILTER isn't optimizable when used in a grid.

>
>Your choices are really to either use a parameterized view or SELECT records into a cursor.
>
>>Can you demonstrate the benefits of deleted() tag using NOFILTER
>>in SQL SELECT command? I always work with real cursors on disk,
>>not with filtered virtual ones.
>>
>>There is a very big bug (for me) in vfp grid control:
>>SET FILTER
>>
>>and invoking grid control for this filtered table causes grid
>>to hang because it will NOT use rushmore.
>>I have an idea that adding a tag on DELETED() allows full
>>rusmoe optimization and can speed up grid control?
>>Have anobody tested it?
>>
>>I tried to replace set filter + grid with local view, but
>>local view always reads the whole table to disk and this also
>>causes computer not work for large tables.
>>Maybe adding index on deleted()
>>sometimes causes local view to put only filter.
>>Will grid control on such view use rusmore?
>>
>>Currently I use set key command. But because the query expression
>>can be virtually any, this leads to implementing oracle or rusmore in
>>foxpro.
>>
>>I cannot make query return small subset of records as in client-server
>>development: search expression can return rows in range 0 ... 200000
>>
>>
>>>
>>>See my post I just made to Andrus. The test table has NO deleted records. It doesn't have to have deleted records to see how the tag help. The number of deleted records will have some impact on the number of rows returned, but that's not nearly as significant as the disk I/O difference between reading the B+Tree out of the cdx vs reading table records.
>>>
>>>>to ALL.
>>>>
>>>>The problem of an index on DELETED() is that it has a very low selectivity. If the optimizer has to return records which are not deleted, it returns about 95% of the entire table.
>>>>
>>>>If you look on other sort of indexes, like articleno in an invoice table, the selectivity could be smaller than 0.1 % (as you have more than a few articles) of the entire table. Now this kind of indexes gives rushmore really a chance to speed up things because it not has to search sequently in the other 99.9 % of records in the table.
>>>>
>>>>As for the deleted index: Do you really think by using a deleted() tag would speed up the query if in the selection of 0.1% (which are made by Article index) are none - aprox 5% deleted records ? This especially counts when this resultset of 0.1% of the table is actualy only about a few hundred or less records.
>>>>
>>>>Nah..... It's better to make sure you've high selective indexes on which an optimizer could really speed up things.
>>>>
>>>>Walter,

Andrus