This, I believe is a key point. SQL Server is a good deal more stable than VFP due to the multitude of things that can go wrong in a fileshare environment.

The worst problem I've had with native VFP stuff is network bandwidth bottleneck as you increase the number of users, especially with large tables.

But the bottom line, of course, is the right solution for the right problem. If you are going to be deploying Internet applications, I would lean towards SQL server too because of the wealth of tools and scalability enhancements that exist when using SQL Server (see connection pooling, etc.). For network apps in a controlled environment, I'd use VFP backend.

Don't be afraid of SQL Server - once you get the hang of it it's not much different than writing a native VFP app - you just have to understand how the different architecture affects application design :)

>>VFP has astounding upper limits. The Universal Thread itself has 400,000 transactions per day. The Surplus Software site averages 30,000 visitors with a daily average of 85,000 to 125,000 transactions. Both sites have VFP back-ends.
>
>I hate to bring this up, but Surplus Direct switched to SQL Server because they had problems with VFP data corruption.