Marcel,

>>However, you are correct in that SEEK will be faster than LOCATE. Because LOCATE uses Rushmore, it must search the tags to find one that it can use. This overhead is the part that slows things down.
>
>This is true If you don't have a filter on the table otherwise SEEK will be slower than LOCATE ( If remove active Tag before the Locate )

See my reply to craig,

about the filter argument: it depends. SEEK can't optimize filters, but to make LOCATE faster than the seek, it takes at least an partially optimizable filter. If the filter can't be optimized SEEK will be faster for the same reason I replied to craig. Internally the two approaches are simular: SEEK searches the indextree, gets the corresponding record and checks if the filter applies. LOCATE constructs a bitmap of indexnodes in memory searches the first match, gets the record an checks if the filter applies. IOW the rushmore approach did win nothing.

If you really need to filter your data you can always filter your index. Though filtered indices can't be used by rushmore, SEEK can.

The power of rushmore lies in the fact that it can combine index information of more than one indextag therefore filtering out the resultset before the actual records are requested from the table. If using rushmore with only one indextag you can achieve better performance in the old xbase SET ORDER TO and SEEK way.

to locate one record:
=SEEK (value, "alias","indextag")

to scan trough records:
SET ORDER TO TAG indextag
SEEK value

SCAN WHILE field = value
ENDSCAN

Walter,