15 years ago the vfp cursoradapter did not exist and the remote views in vfp I considered hackish/unfinished.
But since the vfp cursoradapter was introduced, ***every*** data access is routed through it in everything I develop or can steer maintainance on.
A C/S backend engine is ALWAYS reccommended to clients, SQL server and MySQL given as options already running at more than a few client sides. DBF backend for those insisting IS supported, but might incur special cost if problems are encountered due to cabling, OS and/or client settings..

A my "way or highway" would have eliminated a large client gained a few years ago: they already had EVERYTHING in Oracle, had licenses and expertise. Minimal effort needed to support Oracle, resulted in a positive ROI for the enhancement/adapter layer even in first year (some Oracle tables had to conform to THEIR naming pattern even when introduced via "our" app, so another mapping "logic-layer" in a few cases handled via a table and some generator logic...) and that app is billed as a subscription for at least 4 years ;-))



>This has been my approach to my VFP clients:
>About 15 years ago I gave them all a choice - let us change the backend to SQL Server or get someone else.
>They all went along.
>We did it incrementally. As functions changed, we did the conversions. All new tables are SQL Server.
>There are still a few small .DBF's but all the large tables have been converted.
>The last large one bit the dust just last month.
>All new work uses SQL Server. I haven't created a new DBF in over 10 years.
>If I have to defend why I insisted that they switch to SQL Server, then you and I have a different definition of our responsibilities to our clients.
>
>Regarding using .NET.
>All new applications are written in .NET.
>I wouldn't convert a VFP application to .NET for the sake of converting it, but with each change to a VFP application we ask the question "Can we do this change more efficiently if we convert the app to .NET?" and proceed accordingly.
>We recently converted a VFP6 application to VFP9 because that platform gave us what we wanted at a fraction of the cost of converting it to .NET.
>
>Finally- I think I that one responsibility to our clients is to stay healthy as a business.
>I think we do that best by maintaining a solid technical arsenal that we can offer existing and potential clients.
>