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

You are talking about using hardware and staffing to solve a problem that is basically already addressed in products like SQL/Server and Oracle. In a perfect world, every thing would indeed be perfect. But it not<s>


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

It is true that the VFP team is looking at creating something akin to a view designer for ADO that could be hosted in VFP. But, it is still ADO - and - there are times when you will not want to use a graphical designers. At the very least, you will need to have an understanding of the underlying object model. I think you would be well served to get aquainted with ADO now. As I said at Devcon, ADO is not a replacement for native VFP access. Rather, it is a complimentary tool to be used where native functionality falls short.

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

You, I , and most folks on this forum know that you can do some very cool things with VFP. However, we are the choir. Educating the corporate folks who make decision soley on what the Gartner Group reports is the hard job.

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

Yes, that would address the issue, but you can do that today.....right???