Hi Hilmar, see below ...

>>Hilmar, I don't think you missed something, but I didn't take the time to be 100 % clear;
>>
>>I tried to say this :
>>
>>The view will get all the records you select
>
>Agreed.
>
>>The other thing I said, is that with (native tables) creating the view, this is done within the PC, and in order to do that, ALL the records of the table will get downloaded to the PC. So maybe here is where you disagree.
>
>Yes, I do disagree. The way Rushmore Optimization seems to work is that first, all index keys are obtained. If few records match the criteria, this can be very fast, because the index is NOT stored sequentially - it is a tree-like structure.

1. If few records match the criteria Seek's are very fast too. If many records match the citeria, Seek's are still very fast. So no argument here, I think.

2. Maybe I throw in some other confusion, but my earlier remark that that the index records are stored sequentially was meant super-positive. I mean, when all the records belonging to an index are needed (as with the view which downloads them all (okay, the index-records), it can sequentially read from 1 to x withhout further interruption, AND each block read will contain all (index) records needed in the proper sequence. So, with "sequential" I meant ïn proper (needed) sequence), and not "no direct access".

Now the fact the the index is held by the (multiway) balanced tree (or so) principle, is quite another story. So just for kicks :

Again looking at my remark on the sequentially stored records of the index, I'm talking about the data-block level, which is at the bottom of the tree; the structure above that is directory-block, 1st level of pointerblocks, possibly 2nd level of pointer blocks (etc., but 4 levels will hold huge files already), and at the bottom the datablocks.
I guess you know too, that the according (!) datablock can be found very fast by the tree-sructure and needs the read of the directory block and pointerblocks ("vertically"), so with 4 levels this will be 5, the first 2 or three probably being in the cache.
Now once the datablock has been found, and the whole index - i.e. all the index records are needed, it can sequentially read all the datablocks without intervention of the pointerblocks.

Whether the above is needed by the view or any other normal command (scan while etc.) doesn't matter.

What the view IMHO does, is not much more than creating a physical copy of the index in the local cursor, with the benefit of not having to access the network for the index anymore, but the always present con to first having to download all the (okay, index-) records. Now with the larger file you'll loose, and with the smaller file there will be no nebefit anyway, because after the initial read of the (index) records, all pointerblocks and datablocks to the index will be in the PC's cache. Note that to this respect an index record length of 100 will have 40 records in the 4K datablock, and one pointerblock will contain as many pointers to the next level of 4K pointerblocks or datablocks as the 4K divided by the (32bit ?) offset-reference requires. I don't know that, but let's say 200 pointers per block. So 1 level will refer to 400 index data records and 2 levels will refer to 200 x 200 records. Assumed this is about right, two levels will hold 40,000 index-records. Most of this will be in cache always.

Again there is much more to this (and that's why my original response could be brief only), and that is about the way the disk subsystem has been setup;
I don't think there are many amongst us which will have separate disks for data (dbf) and index (cdx). Now Hilmar, it will be exactly this where you may encounter the difference in speed when you have the view instead of the normal access. I mean, the view will access the index-file only, and since it will sequentially read the file without interruption (see above), the disk's head will not swap at all. But now have the normal access : the head will swap back and forth between the index and the data file, leaving you with the loss of factor x, (about) calculated out of the head's average movement time and the disks spinning (rpm) time. A factor 20 is nothing here, depending on how full the disk is.
Now have two separate disks (and I don't mean Raid5-like) and the head's movement is eliminated. Yes, on the data-disk as well, when the data is in the same sequence as the index. For one user in th system, this is a very very significant difference. And this is exactly what you see when having the view instead of normal access, when one disk is used.

There is STILL much more to it I'm afraid ...
One more example : have the disk(s) 10 times larger as needed, and overall response is 10 times better already. And what does it cost nowadays ? nothing.



>
>However, depending on the conditions, VFP may have to get LOTS of index keys from the index - perhaps most of them. See my FAQ on Rushmore Optimization, for details.
>
>Hilmar.