Hi Walter

I don't think I've spoken to you this year!

>
>>IMO VFP reads an entire IDX file when there Rushmore is used and the IDX expression matches a condition. I believe it only reads parts of the CDX. Specifically, I believe it reads the equivalent of an IDX from a CDX. If I have 10 tags in the CDX, but only 1 matches the condition, only 1 tags' worth of index data is read.
>
>This is not correct. Rushmore theorectically only retrieves the matching indexnodes of a usable index. There might be some overhead to track the indexnodes in the b-tree containing that information, but it is definately NOT reading an entire index tag...

That's right. I was thinking of a theoretical bitmap, with one bit per record.

>
>>Using SEEK (non Rushmore optimized) there is significantly less index data flowing across the wire.
>
>Not entirely correct if you'd ask me. SEEK only searches for the first index match and does not look for more (unless the first one does not meet the filter criteria like the ones in SET FILTER and SET DELETED ON).

I didn't ask. Just kidding. ;) Without a filter, seek should either find the first matching record, or fail within a small number of jumps. With a filter, VFP will move to the next record that fits the filter. I can't think of a way that a Rushmore operation could be faster than a SEEK.

>
>There indeed seems to be another difference between SEEK and rushmore operations. SEEK does not check if the seeked record is dirty if in cache and the refreshing of the readcache relies on SET REFRESH. With rushmore it seems to be that all data come from the network source in stead of the VFP(or OS) cache.
>
>This would explain why I see a performance of a datamungin routine I'm building with SEEK, SET ORDER and SCAN WHILE seems to process data faster than it possibly could get it from the network. With SQL the performance OTOH seems to be linear with the available bandwith.
>
>Walter,

Interesting. Thanks for the info.