>>>
>>>As soon as I changed from filtered tables to views, the corresponding forms, in my application, got significantly faster.
>>
>>... This will be because you read all the records "at once" from the server, possibly by the best (index) sequence, and where the server reads at the block level, you may get 20 records at the time, whereas otherwise you will be reading records scattered over the various blocks, which may come to 20 times slower. This all depends on many things though ...
>>
>
>If you are using a parameterized view, or running a query, and have the appropriate indexes, you don't read all of the records from the server. VFP reads the indexes, but not all of the records.

Agreed. But the reading of indexes are records too (though to be honest, I wasn't implying that ;)
But seriously, it wasn't (originally) about having an index, but a Set Filter. With an index, I keep on thinking such a solution for response-reasons is overdone, i.e. not helpful. Thus, the view will imply ALL the index records read, which will be for nothing if only 3 out of 100 matching records will be used. Right ? Fact is, that all index-records are in sequence in the blocks, so this is fast. But you will loose on it anyway because of after accessing 3 records without view, 3 index-blocks may be in the cache of the client, and 60 are ready to use.

Anyway, please note that the example is about too few records in order to have the general statement checked, and better think of files with over 500,000 records, a Set Filter (no, index) which will give a result of 5,000, data-record with a length of 250, and index-records with a length of 100.
Now you have the view, and I won't. And then let's see who wins, also knowing that our teacher will look at 50 result records only ... {g}
Oh, I won't set Refresh to 1,1, because then I might loose.
(but I can loose anyway ;))


BTW, has the parameterized view really to do with it ?