I agree that more detailed doc would be very nice. I disagree that everything is possible. Practically, tests can give us a pretty good idea of what we have.

Besides that, my opinion is that VFP doc is much better than other MS docs. Also, you know very well that the only perfect doc is the code it self. But even if we would have the code, I doubt we could tell what's the best solution without testing. And who can read all the code, remember it and predict everything? Only the computer. This is why I believe more in tests than docs.

In fact, we have much more doc for VFP today than we had 3-5 years ago. But who reads all docs? Who can remember each detail? Did you noticed how many questions can be answered here simply by pressing F1 in VFP?

I seriously think that something must be changed in the way the docs are made and learned. It's simply too much, products are too big to keep the old style, the pace it's too fast. Peoples must adapt to it. The fact that all products grow all the time doesn't increase our capacity of reading and understanding docs. I believe that more specialization is needed. And when this will be understood, maybe more detailed doc will help.

In the specific case we talk here, I don't believe MS or anybody else can give a simple rule like "Using embeded SELECTs is faster than using separate SELECTs" or viceversa. It's a little more complicate. Maybe a separate book/doc on SELECT-SQL in VFP would help.

What really bothers me is the number of errors I can find (the more a product grows, more errors in docs) often and often in almost all docs (MS or not). This is something that really makes us loose time. Another type of docs/helps I see more and more frequent is the useless one (Like the help for a text box labeled "Path for your file:": "Enter in the textbox the path for your file":)). This is really frustrating and makes me go mad. :)

Anyway, with or without more detailed/precise docs, I will continue to test for my self. This is the only way to go to the "real" world and get "real" results. :)

Vlad

>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.