Edward,
Thank you for your great insight!

I understand #1 - the physical work of writing the file to disk. With multiple-table queries, I can't see any other way to do this; the result cannot be a filtered instance of the original table.
On your point #2 - This is very interesting - do you think there is a different way to obtain the same results?
On your point about related tables- I relate additional tables *only* when there is a condition on them - not for appending their data to the query. So I don't know of anything I can do here.

Thanks again!
Mark

>My assumption is that there are two reasons why larger output significantly delays SELECT-query:
>1) Larger size of output cursor implicitly prompts VFP to create the physical cursor on hard-drive (not in RAM).
>2) If you have multiple filter/joins, then realistically VFP will apply them step by step, i.e. apply first criteria, get bunch of recors (temp cursor), apply second criteria on this bunch i.e. potentially temp reindexing it, etc, therefore time for this temp reindexing can differ significantly for larger recordsets.
>In regard to related tables: there are certain situations when you may get much better speed by substituting JOINs in SELECT with purely interface solution, i.e. you run SELECT against single master file and in form/report pick up lookup fields by SEEK on request (UDF).