>>>>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.
>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.

Then you've managed to make your data even more fragile and added synchronization issues.

Faster? Very slightly possibly. Noticable? doubtful.

Duplicating such an approach with a local SQL instance gives you more deployment worries

Compared to splitting DBFs between machines on a network?? Come on!

>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.

Huh?

>
>regards
>
>thomas