>The only suggestion I can make is to wrap the problem queries in SET ENGINEBEHAVIOR 70 until you have time to go through them one by one and clean them up.

That's what's so wacky. Setting ENGINEBEHAVIOR 70 has no effect on this particular issue. And I'm afraid of trying to go to VFP8 with unknown results.

I'm afraid I've not made myself very clear. To recap, this code will not run correctly in VFP8 with or without ENGINEBEHAVIOR 70 :

SELECT * FROM Custser cs LEFT JOIN ContList cl ;
ON cs.CustSerID = cl.CustSerID ;
WHERE cs.CustSerID # cl.CustSerID

and this code will not run under VFP6:

SELECT * FROM CustSer cs LEFT JOIN ContList cl ;
ON cs.CustserID = cl.CustSerID ;
WHERE ISNULL(cl.CustSerID)

and this code will take a very long time to run:

SELECT * FROM CustSer ;
WHERE CustSerID NOT IN ;
(SELECT CustSerID FROM ContList WHERE ContListID > 800000)

All joins and filters use Rushmore for at least partial optimization

My task was to fix a program running under VFP6. The whole program takes a very long time to run. I'm big on speed, and have tried to use tools like SYS(3054) and coverage logs to eke out the most speed from the programs. The issue that's haunting me is not so much the FieldA # FieldB thing; it's the problem of using VFP8 dlls to run existing VFP6 code. As I stated above, setting ENGINEBEHAVIOR 70 has no effect on this SQL issue running under VFP8.

Also, could anyone elaborate on the sub-select queries? Specifically, if you add a filter condition to the sub-query, the proceesing time goes up dramatically. That's where I was getting twenty minutes to run a query in an earlier post.

I'd appreciate any insight on this issue.