>>>Logically speaking, it is the entire table move across the network and then manipulated in the client machine because VFP table no matter where it resides is still a desktop database / client database.
>>
>>Jess, who cares how it works "logically"? Physically, it does not bring the entire table across at once *unless* it's small.
>
>Bruce,
>
>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.