>>The field is Integer (iActive_Flag <g>),
>Ok, I answered before coffee, but the principle is sound and coffee-neutral <bg>
>
>>but I think there is a change in VFP9 regarding filtered indexes.
>according to help in vfp9:
>"Rushmore can use any open indexes except for filtered and UNIQUE indexes.
>...
>Similarly, Rushmore cannot use an index created with a NOT condition. For example, the this expression can be optimized, INDEX ON DELETED() TAG DEL, But this one cannot, INDEX ON NOT DELETED() TAG NOTDEL.
>
>In the special case that you want to exclude delete records from a query, using an index, as in the first example earlier, will speed up operations when you've set SET DELETED to ON."
>
>I *also* recollect wondering if something I read *meant* that some indexes could now be used by rushmore.
>
>>I'm wondering, if it's documented in Help (it's too late right now to look for VFP Focus CoDe magazine issue, where I read it).
>
>Pls. post the exact wording AND results testing the assumption - not everything you read is true<g>

From the David T. Anderson article:

More Index Smarts

VFP9 is even smarter in how it utilizes existing indexes to achieve Rushmore optimization. For example:

INDEX ON DELETED() TAG DELETED

This index is used to optimize both NOT DELETED() and DELETED() conditions without the presence of a tag created by INDEX ON NOT DELETED()

Just like the MIN()/MAX() optimization, VFP 9 uses a FOR NOT DELETED() filter on an index to optimize a DELETED() or NOT DELETED() query.

-------------
etc., etc.

However, this article doesn't say anything about other kind of filters in indexes, so I guess, I made it up.