Walter,
I think we're saying the same thing. <g>
It's all about finding the fastest way to get data. VFP provides several and no one is always best for a given situation.
Personally I really like the flexibility provided.
>Hi Doug,
>
>>I think the 'trick' here that gives the improvement in speed is the business of
not pulling the whole index over the wire.
>
>I doubt... Both with rushmore (SCAN FOR) and the SEEK(), SCAN WHILE approach only the neccesary indexnodes are pulled from the network.
>
>IMO, The performance difference lies in the rushmore mechanism. Rushmore has to determine if there are usefull indexes and if so, use them for optimization. This whole optimization process takes precious time. With the SET ORDER TO, SEEK and SCAN while you decide what the best strategy is to reach optmimum performance, bypassing any optimizing routines.
>
>Another difference between rushmore and the SEEK, SCAN WHILE process is that rushmore downloads all matching nodes at forehand (taking memory). With the SCAN WHILE approuch the indexnodes are downloaded one by one (taking less memory). When scanning trough very large resultsets, rushmore could be a real problem as the workstation might run out of memory and starts paging.
>
>Regards,
>Walter,
Best,
DD
A man is no fool who gives up that which he cannot keep for that which he cannot lose.
Everything I don't understand must be easy!
The difficulty of any task is measured by the capacity of the agent performing the work.