>Bernard,
>
>David F, in his response to you on this same message, gives you the reason to use indexes. I believe that if you think about it a little you will see that even though it is "ad hoc", the fields which would be of interest would be a limited subset of the whole.
>
>Another thing *probably* slowing things down is the length of what you are selecting. * brings in your whole 520+ bytes record when, hopefully, the query really only needs a small subset of the fields. I believe that this can have a big impact, wspecially when you are selecting so many records.
>
>In summary, use INDEXes for "sensible" fields (including one on DELETED()), make sure your WHERE clause uses identical format as your index and limit the fields you select.
>That will give you the fastest possible query.

Another trick I have used when I had to run some queries on a cinemascope table (you get the picture, right?) was to omit all the memo fields and actually all the fields except the few keys from the query, like this:


use whatever order 0
select field1, field2, recno() as rcn from whatever ;
where [ad hoc query condition here];
into cursor narrow
set relation to rcn into whatever

I've actually included only those fields I needed for building indexes (because I wanted to do some seek()s on the resulting cursor), and pulled all the other fields (one record at a time) when I needed them. Since this was for visual presentation mostly, they never actually needed full details on more than one record at a time.

The machine I did this on was some poor 486/40 or so, and the effect of speeding it up was visible.