Hi Mike,
First thing is an aesthetic issue. Please wrap your code in . Your indentation was totally lost when you posted this.

Now on to the meat of the matter. I liked your use of a composite field. I don't use them very often so I didn't even think about it. I do have some questions about the performance and you may have to just run them side by side to see.

My code creates two optimizable (I believe) queries provided you have indexes on FK (which I know you do) and price_history.price_effective (which I don't know for sure but you probably do). Your combination of the queries makes it non-optimizable (I think or maybe only partially so) because you are using a sub-query on a composite field that has no index whatsoever. Now the subquery may not return that many records; I don't know how many parts you are dealing with so the point may not be valid. The time VFP takes to create and execute an optimzation strategy on 2 queries may be more time than it takes to ascertain that the query is not optimizable and thus brute force it. You'll have to see.

And to me (and I admit I may be biased), two simple queries are easier to understand than one that employs *advanced* SQL techniques. Just my opinion.

Later.

>Heya Larry
>
>Remember that SQL you helped me with recently. It works, but I'm not happy using 2 views to do it. I've come up with a very different version. Would you comment on the performance characteristics of this versus your old one?
>
>FYI, the field names are not the real ones.
>
>SELECT * FROM PARTS ;
> LEFT OUTER JOIN PRICE_HISTORY ON PRICE_PART_FK = PART_PK ;
> AND PRICE_EFFECTIVE <= ltPRICE_Effective ;
> where ;
> PART_PK = lcPART_PK ;
> and PRICE_PART_FK + TTOC(PRICE_EFFECTIVE,1) IN ;
> (SELECT PRICE_PART_FK + TTOC(MAX(PRICE_EFFECTIVE),1) ;
> FROM PRICE_HISTORY ;
> WHERE ;
> PRICE_PART_FK = lcPART_PK ;
> and PRICE_EFFECTIVE <= ltPrice_Effective ;
> GROUP BY ;
> PRICE_PART_FK ) ;
> INTO CURSOR TEST
>
>Thanks!