Larry,

>Here is my SWAG as to what VFP is actually doing. Take it for what its worth. It and $5.50 will get you something to drink at Starbucks. ;-)

Hm, I don't drink coffee, so maybe your advice can just get me a soda? Or maybe I would still need 50 cents for that... *smile*

>As I said in a previous post, you don't specify any filter criteria. What is going on is you are getting two imtermediate result sets:
>
>select * from hpaph0
>select * from arappx
>
>Neither of these is optimizable because you are returning all records from each table so a full table scan must occur. Then VFP (I think) builds a temporary index on the concatenation of the four fields (or possibly some subset of the four) used in the WHERE clause. It then has to once again table scan the hpaph0 and match up the corresponding records. If they match, then the record gets inserted into the final result set.

I think you are right, I was just under the impression that SYS(3054,11) would show what Fox is using for the joins as well as for initial filtering of the tables.

And I am quite sure that Fox is not doing a SELECT * on each before joining, because once I got my indexes blown away and re-created, the query went from taking 17 seconds to taking 0.52 seconds -- obviously some optimization going on there, but no indication from SYS(3054,11) either way...

Vlad mentioned trying VFP 7, and I tihnk I will to see what it has to say!

>If arappx is very small, perhaps using it in a subquery will optimize the query. You'll have to play with it.

I was initially doing a sub SELECT, and I thought that was my problem. I suppose I could go back and try that now, though my existing query works OK now.

Thanks for your time and input! I do appreciate it!

JoeK