Hi Lisa,

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

>I am really not at all sure that this is true. See my reply to Fabio.

>The best way for me to tell you why I think that FoxPro has the ability to set up execution dynamically, outside of SQL, is to ask you to consider the following:

>* -- Fox builds temporary indexes on your resource table dynamically. This has nothing to do with SQL.

Again, this only aplies to SQL, not to the xBase DML. It is part of the SQL optimizer. It is used as a bookmark for processing non indexed joins of results. This is very simular to what happens inside of SQL server.

>* -- Fox has always handled caching pretty transparently and dynamically (which is why we can edit fabulously large text files so fluently), and this has nothing to do with SQL.

I'm not sure what you're trying to say here. Caching (not to be confused with buffering) is a mechanism that takes place on the OS level, not in VFP itself. VFP is smart in when to use caching and when to reread from the data source. However I fail to see where the whole discussion of rushmore fits in here. Rushmore itself does not have a clue about caching.

>* -- the people who built Rushmore, outside of its use by SQL, were pretty smart and may have done things that you are not aware of, similar or related to the above two.

Sure, I don't know the exact implementation details, because that information has not been made public. However, in the experienced I've got, it is not too difficult to see how things fit in, though I must admit that even today I sometimes get suprised with some aspects of rushmore or the SQL optimizer. Also be aware that rushmore was not a radical new idea. The idea of implicitely using indexes was already born in the commercial set oriented DMBSs at that time. The implementation of this in ISAM and therefore record oriented DML OTOH was a very significant improvement.

Over the many years since I've been using FP 2.0, I've experiemented a lot in using rushmore, comparing it with direct index usages (SEEK, SET ORDER TO, SCAN WHILE, etc), using other tools like filemon, studying the file system and caching, knowing optimization techniques in other DBMSs etc, I think I've got a better view and understanding of how optimization techniques work than most people here.

>
>Sorry, you do not find my reply constructive, because I think it is.
>
>
>I accept the fact that you thought that you were being constructive, and just btw I take it for granted that you did not mean to be rude in your tone <s>.

I don't think I was rude here and it never was my intention to be rude, nor do I think that your preceeding message was intended to be rude, though you directly implied that I was not beeing constructive; hence my reply.

Walter,