>
>The index is a separate file; it is processed at the client end simply because there's nothing handling it as a database at the backend - with native I/O, the only services are traditional file server services.
>
>>>when dealing with an index containing a filter, it is not considered for Rushmore optimization.
>
>>Which is contrary to what MS docs. explains. And would you believe that filtered index is much faster than using views? The condition inside the index is rushmore enabled when it is fired but any statement after it is no longer rushmore enabled that's what I've observed so far.
>
>Jess, read Chapter 15 of the Programmers Guide (it's in the online help.) The following is quoted directly:
>
>Indexing Effectively for Rushmore
>Rushmore cannot take advantage of all indexes. If you use a FOR clause in the

INDEX command, Rushmore cannot use the index for optimization.
Yes, and I am talking of the DEFINED INDEX when it is fired. Any underlying code after SET ORDER TO fires is no longer optimized.

>For example, because it contains a FOR clause, the following statement cannot be optimized:
>
>INDEX ON ORDNUM FOR DISCOUNT > 10 TAG ORDDISC
>
>RTFM might be in order here.

MSDN help says this:

FOR lExpression

Specifies a condition whereby only records that satisfy the filter expression lExpression are available for display and access; index keys are created in the index file for just those records matching the filter expression.

Rushmore optimizes an INDEX ... FOR lExpression command if lExpression is an optimizable expression. For best performance, use an optimizable expression in the FOR clause.