>>We are talking of the process here. While the physical table resides in the server, the client will do all the processes in itself bringing down all the data across the network because VFP table is a desktop database. Besides, filtered indexed is not a Client/Server command, it's built in the table. That's why the first execution is slower although insignificannt because the second or third execution manipulates cached data.
>
>No, the filter is contained in the index - the entire index would be grabbed and used as a guide to grab the next record in a SCAN loop here, and clean records would be retained on the local system unless the server marks them as dirty (changed) - there's no prefetch executing the SCAN, and when dealing with an index containing a filter, it is not considered for Rushmore optimization to construct the set of values that are members of the SCAN's working set.

>No, the filter is contained in the index.
Not the Filter Ed, the entire Index definition - w/ or w/o condition. Help me clarify this: Filtered Index has been pre-defined at development time and is fired only when you issue the SET ORDER TO command. That when you just open table without the order, nothing happens. So opening a desktop database is an all client's responsibility because it is still a "desktop."

>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.