Checking sys(3054,11) :
VFP 8.0 - Shows no optimization but uses a temp index.
VFP 9.0 - Shows no optimization but shows (Cartesian product)

I found this thread. Seems to be the same issue I'm seeing.
http://www.dbmonster.com/Uwe/Forum.aspx/foxpro/5717/VFP9-SQL-statement-problem

I'm still researching.

>>>>I've got a method which process 14000 records in a scan loop. On the older machine, the process might take 10 minutes. The new machine takes hours. I've attempted to adjust the paging file memory size, but this hasn't helped.
>>>>
>>>>In the scan loop, there is a replace which is not optimized which is taking about 3 secords per record on the new machine. I realize that the process needs to be optimized but I'm short of time and I don't have time to do it now.
>>>>
>>>>Why would there be such a disparity in time?
>>>>
>>>>The code is identical. The other major change is upgrading from VFP 8 to VFP 9.
>>>
>>>Is it one record replace or multi-records replace? Also, do you have triggers / rules in the database that are fired along with the replace?
>>
>>Wow that's the first time I heard the "Reply".wav after someone responded to one of my messages on UT. I think they should've used a deep masculine voice, instead. That really would've blown me away.
>>
>>No triggers or rules. They are multiple replaces over 8 million records. I know how to optimize this and will when time permits. But I've got to get this and about 30 other methods :) with similar problems completed in a very short time.
>>
>>And the biggest question is why is it different from machine to machine. Other than the hardware and the upgrade, everything else is identical.
>
>Check if the CPCURRENT() is the same as CPDBF('TableYouUpdate'). That could be the first problem if they are different.
>
>Other than that, it's hard to say what changed after upgrade, so I suggest to bite the bullet and make the needed changes.