>>I'm actually in the process of doing the same thing (only going from VFP6). I've done this several times in the past as well.
>>
>>From what I've gathered there are several ways to go about it. In my case the application is only going to be around for another year or so and it's HUGE....so all I'm really doing is this:
>>
>>SET ENGINEBEHAVIOR 70
>>SET TABLEVALIDATE TO 0
>>SET REPORTBEHAVIOR 80
>>
>>...which for all practical purposes finishes the job (that and make sure anywhere you use the LOCAL statement you have comma's between the vars...
>>
>>So if you have something like this:
>>LOCAL lcVar1 lcVar2 lcVar3
>>
>>Change it too:
>>LOCAL lcVar1, lcVar2, lcVar3
>>
>>If you do the above then in theory the app should compile and you'll be just fine. If you don't want to use the SET commands and make it more VFP9ish, then one of the things you have to keep in mind is how the GROUP BY clause has changed......
>>
>>
>>
>>
>>>We are upgrading our legacy financial app from vfp7 to vfp9. Are there any papers out there pointing out gotcha's and pitfalls?
>>>
>>>Thanks..
>
>
>Thanks for the reply. We always use commas to separate variable definitions as per our standards. But the Group By could be huge.

Having done it both ways, I agree with both things you say. SET ENGINEBEHAVIOR is a hack, yes. And doing it right -- finding all the Group By clauses (trivial), changing as needed, and retesting -- can be substantial. It really depends on your future plans for the app. If it's going to still be around for a while, my tendency would be to bite the bullet and do it right.

PS -- I am not "back back" so no lectures, please. Am still focused on sobriety and that is going very well. If I do start spending time here again, I'm going to be keeping it light or technical.