>Hi David
>
>Once you issue SET FILTER and then GO TOP or GO BOTTOM, the dataset should already be "in memory". It should not be necessary to issue GO BOTTOM / GO TOP after each seek. I'd expect the record pointer movement to be slower than a seek without an active filter. SEEK is not rushmore aware. If the seek lands on a record that is subsequently excluded by a filter, it will take time to move to the next record.
>
>You might try using LOCATE instead of GO BOTTOM. GO TOP / GO BOTTOM are also not Rushmore aware commands, and I suspect Larry is trying to reduce your overall timings. I thought you're trying to contract seek vs indexseek. IMO as long as you're using the same command after the seek/indexseek, you're still comparing apples to apples.
>

Hi Mike,
I disagree here. It would be true if the "same command" were not affected by the environment changes. However, applying a filter has more effect on GO BOTTOM than it does on INDEXSEEK/SEEK, IMO. I still don't think the test is fair with respect to the two commands.