>Hello Everybody
>
>I try to summarize all what I've read here and there about velocity in Data fetching and rushmore optimization. Some questions came into my mind after reading the interesting thread of last March about Deleted() tag and Rushmore optimization: I've picked some ideas that lead me to the following:
>
>Here is what I believe I have understood:
>
>If my (VFP)data are located on a server, each time I run a query through the LAN, I fetch all the records of all the tables involved in the SQL Select statement. Let's suppose there is only one 3MB table involved in the query: it would take about 3 seconds to fetch the table (on the idea that my ethernet LAN has a 10 KBits/sec speed): it's an eternity!
>
>In the same time, I read that rushmore optimization should be based on a local copy of these tables index files (March thread about Deleted() tags).
>
>If I understand right, I think that, compared to a non optimized query, a fully optimized SQL statement will:
>1- run against the local copy of the index file
>2- and then will only get the selected records from the distant table (or even only the desired fields), reducing both volume of repatriated data, trafic on the LAN and time of the query. This instead of fetching the whole distant table into my client station and processing the SELECTion on the local machine.
>
>In other words, does Rushmore optimization prevent to import the whole tables into the client machines each time a SELECT is run?
>
>Do I understand well?
>
>Selection processing is rarely clearly explained in guides or books, overall these subtleties about the way the data are fetched within or without Rushmore, about what exactly (whole tables? All records? Just some of them? All fields? Just some of them?just index tables?...)is repatriated when one runs a query.
>
>I hope to get useful answers to my questions and I'm sure that lots among us will be interesting in having the answers to these questions that remain vague to many.

Rushmore is the mechanism to utilize ready-to-use indexes when query is launched. So, if VFP cannot find an index and Rushmore is on, then it will create temp index first and then again use Rushmore. However, the point is that index will be used anyway (ready-to-use, which is faster or temporary), so VFP manipulates only indexes during the query processing, and when all 'index' process is finished moves result table records. So, the tale about VFP moving whole tables around the LAN is completely (or partially: depending on attitude :-) false.