Yes that's true. I've preached before about using remote views to hit VFP tables so that all you have to do is change the connection string and then have all your remote views point to something else like SQL Server or Oracle. Of course most people are not going to create their VFP apps that way from the onset. Even so I would *think* that even if you had to deal with such an issue that it would probably still be less time consuming than doing a total re-write to something like C#. I guess it would require doing an analysis to determine if it's worth doing and its going to be different for every case.

>Not necessarily. If all your VFP data access is using SEEK, LOCATE, REPLACE, etc, you can't easily migrate to SQL Server.
>
>>That's the way I look at it. Another thing is that you can do is if all the data is stored in VFP tablesm you upsize to something like SQL Server and still use most (if not all) of your VFP code. Now once you've got them running on the new backend, you can now work towards a new frontend UI. From a selling point I've had pretty good luck with that - they don't have to invest for a total re-write yet, but they can get some code enhancements and a stronger backend and position themselves for an easier rewrite/upgrade later as the data is already ported.