>What I am *NOT* for is limiting VFP (apparently) in order to sell other >products like SQL-Server.

The DBF file structure has zero credibility in the client/server world....period. DBF's and SQL/Server are worlds apart. To say that VFP has limitations forced on it to help SQL/Server Sales just does not make sense to me. If you wanted to direct your argument towards VB, then I would begin to see your point.


>No, I do not at this point use VFP Server(s), but that's because of the >present limitations of such, at least as I understand them in VFP 5.
>I would *love* to use VFP servers, in the sense of a server - a server which >can handle *many* concurrent requests *AND* a server which can "serve-out" >request data, be it as records or record-sets.

What kind of activity do you need to support? Have you tested VFP servers to see if they would fit the bill? Before dismissing them, you may want to test them in your scenario. ADO is based on the VFP engine and is the solution you are looking for. I don't see why you are put off by the fact that it is not bound in VFP. To me, this is a good thing since 1 data access strategy can exist accross the toolset.

>The oft-quoted Euro-Tunnel project shows that there are ways around the 2-gigs >per table issue. The recently publicized JFast military application shows that >SPEED and complexity are still strengths of VFP. In other words, with a VFP >which FACILITATED VFP-to-VFP communication *including intrinsically doing the >I/O for clients and giving clients back the record(s) they need in the >"native" format expected, we could have our cake and eat it too!

Right, you have always been able to do this stuff. That said, I am not sure what your argument is???


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

I agree with these two reasons. Scaleablity is another factor.



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

Not sure about this. What does VFP have to do with the impossibility of pulling the plug out of a machine??