>
>I believe this was due to a bug in a certain version in a certain situation. This should not be true outside of this bug. IOW this is a trick to cercumvent a certain bug rather than it is a rule in rushmore.
>
>
>It has nothing to do with a trick or a certain version. And it was never a bug, it has been a documented fact about Rushmore for a long time.

I´ve not seen any official MS documentation saying this. IMO, it is not directly a rushmore issue since those subscribed (malfunction) differs when using xBase optimizable expression and SQL SELECT (See fabios observations). Since it has been described that

Expr relop indexed_expr

is just optimizable as

Index_expr relop Expr

(see VFP6 documentation, I did not check later documentation here). From a logical point of view the issue does not make sence at all. I see no reason why this should be a function rather than a malfunction or bug).

>I do see that the documentation now indicates that you can write the expression in either direction... but I'm pretty sure this behavior has not changed.

The documentation has been saying this since FP 2.0 AFAIK. So there either is a bug in the documentation or the implementation.

>Let's try this with a table we both have, shall we:

<snip>
with SQL you´re right. However with xBase commands, its different.

>
>I'm not sure what you're telling here. In general Rushmore does not give a damn about the ordering of the conditions. So your statement above does not make sense to me at all. In both cases the applicable index bitmaps will be downloaded from the table and joined. As a result the resulted records will be downloaded from the table
>

>I'm sorry it doesn't make sense to you. Where the conditions are joined with OR, both sets have to be downloaded and joined. But where they are joined with AND, it can work differently, as I said.

I have to see the test that prove this (I dont say you are wrong here thoug). The dreaded DELETED() tag did show otherwise. It alsway loads in its enterity regardless of the other rushmore optimizable expressions. AFAIK, I,m glad to admit that I don´t know every little details either, rushmore will download every index bitmap independly from every other index bitmap in the expression. The order in which the bitmap values are joined we have little control over (except some very limited controls in the SQL FORCE clause in Joins)

>Many people have shared their experiences and tests on this subject and have concluded that Rushmore (similar to SQL Server and other database servers) can choose a different optimization path at will, depending on a number of factors. For example, it is acceptable for the optimizer to decide to build some temporary indexes, and it may do so *sometimes*, against the same query, depending on memory factors or the size of the potential result set. Perhaps this happens more frequently when multiple conditions joined by AND are involved, because the optimizer decides it's more fruitful.

This is only applicable to the optimization in SQL SELECT and in fact does not have direct relation to rushmore as described. The optimization algorith implemented for the SQL engine is responsible for that, not rushmore. Rushmore is the technique that uses existing indexes to optimize expressions. The optimizer builds on top of rushmore to examine the query and decides the execution plan for the query. SQL has a execution plan optimizer; the xBase DML has not, though both use rushmore.

>
>Yep, but keep in mind this is only giving you an advantage if you have to run through the set more than once
>

>I believe I maintained a clear focus on the fact that he was going through the set multiple times, throughout my reply to the gentleman who needs the help, Walter. If you have something constructive to add, to give him more or better advice, please do chime in and provide it to him.

I think the gentleman already has received enough replies to get further with this. My reply on your mail was only intended to "clear up" some statment and deepen out the subject. Sorry, you do not find my reply constructive, because I think it is.

Walter,