>>I built a view with the view builder, combining table1 and table2, and filtering as follows: table1.group is a character field that can be 'a', 'b', or 'c'. The user will choose to include all 'a' and all 'b' and exclude 'c', or vice versa. To make the query work, I made public variables (eventually to become app object properties) group1 and group2. If the user chooses 'a and b', I set group1 = 'a' and group2 = 'b'. If group 'c' is chosen, I set both group1 and group2 = 'c'. Group1 and group2 are also query parameters. The query looks like this:
>>
>>SELECT table1.orderfield, table1.group, table1.field1, ... ,table1.field5, table2.field1, ..., table2.field8, table2.memofield, table2.key, table2.field9,...table2.field50 FROM mydata!table1,mydata!table2 WHERE table1.key = table2.key AND (table1.group = ?group1 OR (table1.group = ?group2)) ORDER BY table1.orderfield
>>
>>Table1 has 6000 records and is 2.5MB with a 0.5MB .cdx. Table2 has 2300 records and is 5.2 MB with a 94 KB .cdx and a 78 KB .fpt. I have indexes on table1 key, orderfield, group, and DELETED(), and table2 key and DELETED(). If 'a and b' is chosen, the query takes 16-22 seconds, running on a P166 off a network drive. If 'c' is chosen, it takes about 10 seconds. Could I do anything to speed this up?
>
>Your SELECT seem to be optimized. You can check it out with SYS(3054).
>
>The response time may be affected by 3 things: the amount of RAM in the PC, the traffic on the network and the amount of data that the query return.
>
>I would suggest at least 16MB of RAM for running VFP (preferably 32MB)
>
>Try to do your benchmark with local database to see if the time improve.
>
>In your example above, probably that the group 'c' contains less record than group 'a' and 'b'.
>
>HTH

I keep forgetting to mention that I still use vfp3. It doesn't have SYS(3054). Moving my database to c: brought the times down by 40% or so. The first time I run each query, they take almost twice as long, probably because some temp file has yet to be written. I have 32MB RAM. One of my users has less. When this database was separate from another database and was simpler, Table2 was loaded by itself in a form. Connecting table2 with table1, which used to be in a different database, necessitates this view. My users are going to grumble when this same form takes 10 times as long to load. Group 'c' does indeed contain fewer records than group 'a and b.'

There is one thing I may be able to do in the future, but not right now. Fields 9 - 50 might be removed from table2. Removing them from the query doesn't make much difference, but removing them from the actual table might. They are all the same size, and most of them are empty. I might put them in a child table.