>>>That is called SQL Server. You can still write VFP apps using it and eventually port them to a different front end if needed.
>>
>>Perfectly aware of that point, but that is not applicable to everybody. If scale of business / data is such that it requires MSSQL (or mySQL, FireBird etc ) then yes by all means. Application would get a bit slower then straight Fox but that would be ok. Problem is
>>that once you deploy full size database many of realities change ;
>
>Why would it be slower?
>
>Unless you are only using small databases exclusively on a local machine, SQL will likely move data faster. When you start working with databases of significant size, SQL will move data faster unless you are running a SQL server with very limited resources.

Agreed that in non-trivial data sizes *moving* remote data with a sever is faster with most C/S backends,
even if using central dbf tables was safe and sound - which it is not and gets less by each SMB#.
But if you divide your data into local replicated lookup data and central data, there is a good chance that this vfp-approach
is faster than using only remote SQL data. Duplicating such an approach with a local SQL instance gives you more deployment worries
and either you are still bound to munging in at least theoretically less scalable memory with nonSQL or LINQ or
have to pipe the remote result into your local SQL instance with probably less support for updating the backend automatically.

regards

thomas