>Hi Jim,
>>
>>On the assumption that even Rushmore does NOT provide data from indexes to the program, why would Rushmore's bitmap be of any use when reading records contiguously?
>
>Scenario 1: No records to read at all<g>. Cdx disk IO saved.
>Scenario 2: Seek-Scan is used only to speed up, walking in a different order is only a by-product, walking sequence "really" is of no consequence. Scan in the seek-scan scenario has to read the cdx "before" each dbf-record pointer movement. If scanning via Rushmore's bitmap, the dbf-records are accessed via the bitmap and the cdx overhead is saved.
>

Hi Thomas,

AFAIK, a bitmap driven SCAN is faster only on filter conditions (FOR) and that the Rushmore bitmap is created based on ALL relevant indexes. Could it be possible that, once an order is set on the data, all bets are off since the bitmap may not be rendered in the desired order? In fact, an optimized SCAN FOR is (much?) slower than a SCAN WHILE once the order is set. Also, the VFP9 help on Rushmore states that
For optimal performance, don't set the order of the table.
... If you want to take maximum advantage of Rushmore with a large data set that must be in a specific order, issue SET ORDER TO to turn off index control, then use the SORT command

Probably, the assumption is that when using SET ORDER TO something, the walking sequence is of consequence and the bitmap is not optimized for that.

Maybe a bitmap would speed things up on SCAN WHILE, but not a Rushmore bitmap.

Regards,