My suggestion of moving to VFP9 was primarily geared to the improved syntax for VFP SQL that would be more compatible with .Net when he makes that jump.

Especially since most of the stuff he has is Use/Scan/Seek type of programming, the conversion should be very fast and clean if not fully compitatable. This way he would learn better SQL syntax as he starts to do that.

He should get a copy of VFP9, point the project at it and compile, and see what happens. Chances are good he can upgrade VFP versions with very few lines of code and might not require any change at all.

Bob


>>>>I need to migrate to VFP9 first (yes I know not 100% necessary but desirable)
>>>>
>>>>Then I need to move to SQL server
>>>>
>>>>Then I need to move to .Net
>>>
>>>You don't need to go to vfp9 to use sql server. We have it here in both 6.0 and 7.0. Do you have to move to 9?
>>
>>John
>>
>>Now that's really helpful - no I don't need to move to VFP9
>
>You don't need to, but you might WANT to if you have ongoing VFP projects into the future. The view designer improvements alone are a huge benefit -- you can actually mess around with the SQL statement in the view designer and have the graphical and the textual changes affect each other in a true two-way design fashion.
>
>Come to think of it, you could actually do the same with the free eView -utility and VFP6. In the same vein, while Code Reference is a nice feature in VFP9, it doesn't allow you to edit code, whereas GoFish -utility lets you do that and much more and do it MUCH faster to boot.
>
>So, maybe you don't need VFP9 after all, maybe you just need a few of the VFP 3rd party utilities to make your VFP6 life as easy and comfy and cozy as it would be under VFP9...
>
>
>Pertti
>>
>>Sadly all my table work in VFP6 is individual calls which means a hell of a lot of changes - any tips on putting SQL in as backend?
>>
>>Thanks
>>
>>Colin