>>BTW with 800-2000 recs 'speed is reasonable' - if you mean it's noticable but acceptable then actually you should investigate bottlenecks in app.
>>Cetin
>
>Thanks for the info, Cetin. I'll check into the Set Key idea.
>
>As for bottlenecks, I'm not real sure where to look. Imagine a form, showing some basic fields and a basic toolbar that moves the record pointer forward or backwards. The form is bound to a single table. The data is filtered (based on the teacher code). At some schools, the time it takes to go from one student to the next is not very fast (a second or two) but at most it's instantaneous. How could I improve the speed is the basic problem (which is why I asked about views.) I truly feel that at some of the schools the network is a bit slow.

Patric, try to look at it this way :

The Set Filter will read all records, but will present to you the fitered records only. Thus, when one out of 100 match, 99 will be read for nothing, AND will go over the line (supposed you have native VFP tables, and not a remote DBMS). So that's not handy foro speed.

The view will get ALL the records over the line, and the (again) Set Filter on the cursor will do the same as before.

According to the above, the view is always slower, unless you have the filter on the view as well (i.e. only get those records in the cursor you want). But :
This is not true, since again (native tables) all the records have to go to the PC first in order to being able to apply the filter.

So up till now the view is always worse.
Now the above is about having to read too many records in order to show a few only; When the teacher will never get to see all the students, it's always supid to read them all. Thus, when he only clicks the plus and minus, and after three students he's seen enough, the view didn't help at all in any way. And the filter the same (this doesn't need more explanation I think).
However, when the teacher would have all the students in a list anyhow, the view might be better afterall, because the filter would go the server over and over again, and the view was only drawn once.
But I suppose this full list is never there, though I wonder what would be the logic of enabling a one-plus-skip only.

From balancing things you should be able to dicide by the above what's best for you app (I hope), but think of this too :
Where the view might be better after all the records are loaded into the PC's cursor, that will be relatively VERY slow if the network is slow. Again, this comes to : does the teacher need the full list at any time ?

When you understand the above a little (and I am not too wrong on it;) you can decide for the real solution : have an index (the Set Key solution);
Once you have this, there is nothing to decide for anymore, well, not in normal situations. I mean, when you use the index you'll be reading nothing for nothing. Now you still may use the view to make this faster, as long as the view (cursor) is build via the index. But to be honest : this is doing difficult, and you might just as well copy the "filtered" records into a local table and use that one (being equal to a view's cursor in fact).

HTH,