>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?
No; the concept of Rushmore is that the data file itself isn't read until the result set is needed; it first attempts to use the .CDX file to service elements of the query to restrict the record set needed to solve the Select statement, and only then will pull data from the file to resolve any query elements that cannot be serviced by existing indexes. It builds temporary indexes as needed, and these do not persist beyond the query, so that if the elements of a query can be serviced from existing index tags, only the .CDX file segments and the result set of the select cross the wire.
If you issue queries whose elements cannot be serviced using existing indexes, VFP will be forced to read the table(s) involved and build temporary indexes to service the query. These temporary indexes are non-persistent, so that each query will result in having to re-read segments of the table not held in the local machine's cache. Some query elements are never solvable using an index (for example, substring searches of a character or memo field) which will result in moving large volumes of data across the wire each time the query changes.
>
>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.
