Jim,

There's no such thing as an environment where a server can't crash or loose power. By the time you get VFP to the point where it will offer the features of SQL Server, it will be just as expensive and complex as SQL Server. In the mean time, Microsoft is working hard to make SQL Server easier to use.

VFP just isn't a server database. I think if MS tries to make the product do anything, it will end up too big and unwieldly to do anything well. It seems to me that the best way to do things is to choose the right tool for the right job. VFP isn't best for everything any more than VB, Access, and SQL Server are.

>Two major reason always given for going to SQL Server (or any other SQL-type back-end) are:
>1) much greater protection offerred by a back-end solution;
>2) much greater data sizes available.
>
>Well, the "protection" aspect could quite well be taken care of *IF* we could run a VFP Server which would be in a controlled, power-protected environment where pulling the plug or sudden turn-off or power failures couldn't happen. It could be responsible for all database read/write actions, SERVING clients the data they request.
>Sure, this might be much like what SQL provides, but it would be at a much lesser cost and it would involves far less secondary costs like education/training or overhead, etc.
>There would still be a use/need for SQL Server type capabilities, but a much wider scope for VFP-style applications. Users would then have a legitimate CHOICE.