I was not advocating that people should necessarily stay with .dbf files; typically our backed is also SQL Server, although MySQL comes up and once in a great while Oracle.

>> My responsibility is to the client.
>As it is for all of us.
>However, what is best for the client often exists in the eye of the consultant.
>
>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.
>