Vlad,

Yes, we can make tests. But all that such test *really* prove is that, for THAT exact condition, the result can be predicted.

Another field *might* change the result (performance-wise) dramatically. So might even a different type of field, or even a character more or less in a field.

Knowing virtually nothing about HOW VFP-SQL is designed to work, and this certainly appears to be MS' basic way of doing things (at least in VFP), we can only really *GUESS*.
This is one strategic area where VFP gets serious frowns from informed management - keeping programmers "in the dark" as a matter of policy is *NOT* something which inspires CONFIDENCE.

We need to be given a fighting chance to make great applications. Trying something 93 ways is not my idea of a "fighting chance".

The same goes for bug fixes, where we may well have "workarounds" in place which make for slow and/or kludgy code. By keeping the list of fixes secret (as they did for oh so long, and seem predisposed to do) we get *no* chance to remedy such "bad" code which we may have deliberately placed in our programs to work around VFP problems.

In summary, you can learn *something* from doing your own tests, but not nearly as much as you could if you were also informed of the design objectives/parameters/limitations of the product in question.

Cheers,
Jim N

>>What do you know about how VFP handles SQL internally? Right, nothing (the
>>same apply to me too ;).
>
>:) You're right. We don't know much about the implementation of SQL in VFP. But we can make tests. And in this kind of problems, I never saw one that is faster when is done in 2 steps. This is why I asked you: to be sure that what I observed is correct.
>
>> I know how to speed up SQL with Rushmore (if it's
>>simple), but I know nothing about how VFP handles Union clause or nested
>>selects. May be it's my personal habit, but I like do calculation process
>>step-by-step, it could be more understandable after two-three month...;))),
>>After all, this doesn't matter ;)
>
>It matters a lot. And I agree that sometimes you can/must trade performance for readability. But this doesn't mean readability = performance. :)
>
>Vlad
>
>>
>>* Will write login scripts for food
>>
>>>Why are you so sure? Do you have a case for it? I never could get a
>>faster
>>>program using 2 SELECTs when I could use one embeded into other. This
>>goes
>>>for cases similar to the one discussed here. It's true that for other
>>cases
>>>you may have a better performance if you can separate.