>Yes, I do want to try running these tests with all tables on a local drive. I just normally go for the "across the network" tests firsts because in my environment I've seen a big difference, with network response being not so good when local performance seems fine. (Users are never accessing local data once code goes into production)

That's true and it's sure that you must do tests in a network environment if the app is for network. But usually, the local tests are good also for the network: ie the best local solution is the best on the network. Still, I saw many cases when this is not true. :) The problem is that if you want to compare 2 solutions, is difficult to reproduce the state of the system. Bla, bla, bla, I'm sure you know all these. :)

>>Also, extremly important: close and reopen VFP between each 2 SELECTs in order to get accurate results. VFP is optimizing from one SELECT to another when this is possible. Since the SELECTs are on the same dbfs, it's almost sure some optimizations are done as you pass from one SELECT to another.
>>
>
>I seen that when I first started, thats why I alternated between the 4 queries.

The alternation is not good enough because you don't know what optimizations are done when A,B and what optimizations are done when B,A.

I had once 5 SELECTs to test and I used your method (very scientific, I had a program that was doing everything for me, randomly, etc:)))). The "best" one was about 10% ahead the others. But, in practice was really bad. I still don't have any good explanation for that situation. Probably some very different optimizations where done depending on the sequence of SELECTs, but I couldn't imagine what. :( Anyway that SELECT was the fastest when it was run after another SELECT and the slowest when it was the first one.

> But good point, I will try this first and let you know if I see any different results.

Vlad