>>>Which arguments do you have to not move fully to SQL Server and abandon VFP Tables?
>>
>>Some arguments were given earlier in this thread:
>>1- support clients who can't afford or don't want a SQL database
>>2- be able to migrate clients one by one without supporting 2 code bases
>
>OK, that said, the SQL Express version supports 10 GB of data, so it will depend on the size of the database if they need to purchase SQL Server.
>
>Regarding migration, I would imagine that if the data structure stays mostly the same, it would not be a real big problem to convert existing clients.
>
>So my conclusion is, check if old clients can use SQL Express with the 10 GB limit, and check if an automatic data conversion is possible. If both are possible, supporting VFP tables is not important and only creates additional work.
Hi Christian
Looks easy on the paper, not from my experienced POV.
Once you migrate as you propose, how do you manage evolutions in the software? do you duplicate your code, one for DBF that evolves, one for SQL where evolutions are postponed later? Or do you apply evolutions to both 'versions'?
Did you experience this overnight, all-client-at-a-time migration?
Thierry Nivelet
FoxinCloud
Give your VFP application a second life, web-based, in YOUR cloud
http://foxincloud.com/Never explain, never complain (Queen Elizabeth II)