You are somehow right. Ie: you're right about the results. This is exactly what I explained last week about scaning with or without an index.

But the cause is not (or, at least, I don't believe it is :)) the filter optimized by Rushmore combined with the order. During the Rushmore optimization, FoxPro builds a bit array BEFORE starting to scan the table. After that, during the scan, FoxPro checks each record against this array. (BTW, this is why some modifs may be not seen by FoxPro during a scan when SET OPTIMIZE is on.)

I believe the data caching is responsible for this effect.

Maybe you're right and I am wrong! :) Does anyone know something for sure? :)

Vlad

>What I mean is that since Rushmore uses the available indexes to determine which record to go to next, a filter on one field with an active index on another field makes the system have to parse thru two indexes at the same time, which in my experience greatly slows down the searches.