I will see if I, too, can intersperse my responses as you have. . .
>>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.
>
I *strongly* suspect that the main reason that the DBF structure "has zero credibility in the client/server world. . . period" is that tables, and especially indexes, are easily corrupted when something 'unusual' (usually involving power) occurs. That's a dicey problem indeed!
But with a Server entity as I am trying to describe, this problem *could* be virtually ELIMINATED - a machine operated by professionals in a secure area with UPS would be responsible for all database read/writes (the VFP server) while client machines would be free to do what they pleased (including pulling the plug). Simple, really. Where's the credibility problem there???
>
>>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.

Here I have to admit that I haven't looked at ADO. My reluctance stems from 2 sources. First, I *prefer* to try to keep my solutions 'simple', without the need for other products and/or services. Secondly, since Mr. Green had made indications that some of what I want is being worked on, I elected to await that instead of cluttering my (limited) brain-space with yet more stuff (ADO) which I may use only rarely.
>
>>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???
>
My argument here is that you *CAN* do some very large and nifty things with VFP as THE database engine when a little creativity is applied. It is not a 'no-brainer' that, at some point, its a MUST to move to some SQL engine.
>
>>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, it begins to sound like "scalability" will ever be so, with VFP's shortcomings regarding Server/MTS capabilities coming out as they now are.>
>
>
>>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??
Hopefully my earlier response above clarifies this for you (seems we cannot read what we do not want to read, maybe). One would *NOT* pull the plug or lose power on a professionally operated VFP Server machine in a secured environment with UPS power. This machine would be where *all* database read/writes are done (VFP-to-VFP, clients specifying, Server DOING). Clients could pull ther plug all they want without jeopardizing the data. Is that clearer????


Cheers,
Jim N