Fabio, thank you for cleaning up the test program. I adapted your test code too quickly, and I apologize for that.

I don't know what I was thinking, I was probably too tired to think at all when I did this!


To answer your additional questions:


If you read my first message to you, you can found this,
with "==" the right comparison disable the optimization:
The problem is : where is this documented ?
Is this by design, or is this a side effect ?


First, the optimization of == was done *after* the optimization of = (originally it was not optimizable at all). So although it may not be "by design" we can assume that there are some differences in implementation.

Also, if I remember correctly, it was optimizable in SQL before Xbase commands. So there may have been several phases of implementation. At any rate, originally the word from Fox was that == was not optimizable without changing the way == operated, and this changed later.

Second, I don't know if it is documented or not.

Third, integers are a fairly recent addition to FoxPro and although we can make some guesses about what your finding regarding = and == indicates about *how* they are implemented... I'm not going to speculate further about this<g>.

Fourth, IN SPITE OF EVERYTHING, I really don't see the point of including cases where you actually *set* the index to the appropriate one in order to get the help of the index, in the context of a discussion like this <s>. As I said, you can always do a SEEK and a WHILE in those cases. Rushmore doesn't get used but you don't need it.

And, finally:


1. The VFP(T) "intelligent" optimization is not the possible best in many cases.

2. Why want you put SQL Engine rules into DBASE Engine ?


1. Yes, that is probably true. What's your point <g>?

2. I don't, necessarily! However the FoxPro engine does have rules, and its implementation of SQL does leverage the same rules where Rushmore is concerned, in many respects. As a result, sometimes I do try to draw inferences from what evidence is available on the SQL side.

With reference to this discussion and how Fox manages things internally, I think that it is possible for Fox to create temporary indexes at will to manage certain operations, and that it will take many factors into account when deciding whether or not to do this. It may not be the same as a SQL Showplan exactly but I have always thought that it could do this for Xbase commands as well as SQL ones.

My evidence for these temporary indexes, and potential different paths of processing, rests on the work of many fine developers and their tests through various betas. It is not an area in which I have concentrated personally, but many other people have.

In looking over past messages (both from Fox and later MS personnel and testers), I have no indication that this happens outside of SQL commands and no indication that it does not. I have no "inside" knowledge of whether this is something that *used* to happen and no longer happens in the product, either.

But I have to ask you: Why would you *not* want it to do this?!?

>L<