>>So if I interpret your lines right, you will have a Select on all what you need, and use a view for it. So in your words : only a few child records will be in the result, and I say : have your Select without the view; the view is overhead.
>
>Peter,
>
>This is a symantical argument, in VFP a view IS a SELECT, except it is predefined and stored in a DBC and can be easily made updateable and treated as a table with the USE command etc.

I may hope I knew that. However, when we'd go on treating the Select the same as the phenomenon View, what would be left of the cursor ?
And yes, once I was looking for the definition of Cursor, which sadly can't be found anyhwere in VFP help or MS-VFP-guides. But never mind :
The view is a predefined "view" on a (set of) table(s) and the fields in them, and once it has it's data downloaded, we can look at it by means of a cursor. And yes, the view is a pre-defined Select.

The result of a Select can be looked at by means of a Cursor.
And ... the Cursor can be apporoached by means of a Select, the result being in a Cursor again. And, IMO a View can be made for a Cursor.

Cursor = result-set is more understandable.

If I'm wrong please say so, knowing that the above is my own adaption from things.


Looking at the first lines of this Meesage from Hilmar, and my response to it, it looks like mixing up things (honestly, this can hardly be read otherwise), which originates from a. the view to download the complete "Set Key" of a table and b. any filter which could be applied afterwards, or just the Seek to the records needed. Anyway, my words were confusing (excuse me Hilmar !) and I'd better said : perform a Scan While and forget about the view.
Now "Scan While" as a solution is still stupid, once our teacher wants to look at the three (subsequent or not) students. Do Skips or Seeks or whatever.
Getting dizzy here. Sorry.