No, Josh, I *think* you are reading much more into this than I am proposing.

ALL that I am really asking for is a VFP-to-VFP communication capability which correctly handles SQL requests including views (and I would also like it for *any* I/O type VFP command, but that's a (slightly) bigger issue. No ODBC. No SQL-Server. No ADO. No anything else in the middle except for the standard OS things needed for such stuff.

NOTHING fancy like SQL-Server per-se. Still a 2-gig limit on tables and CDXs. Still all of the things as they are today in VFP (from a tables limitations/mechanism point of view).

Baisc simple VFP-to-VFP, which already has some very intelligent code for buffering, which I presume to be the key issue in this. Of course this VFP-to-VFP has to be able to handle multiple clients to a single (or many, for all I care) Server-VFP(s).

Nothing fancy, but something very useful, giving me the chance to present clients with lots of protection for little added cost while at the same time greatly decreasing line loads by transmitting only valuable data (if well designed apps are deployed).

Cheers,

Jim N

>>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???
>
>Jim,
>
>I don't understand why you wouldn't just use a product like SQL Server if you need reliability. Trying to create an environment where nothing ever crashes is impossible and even approaching it would be much more expensive than moving to client/server. What crash proof operating system will you run this server on? Call me right away when you find one!
>
>Wouldn't VFP server database look a lot like SQL Server? This whole argument makes no sense to me. If you need a database server, why not just buy a datbase server? When I want to make toast, I use a toaster. I don't ask Microsoft to add toasting capabilities to VFP (although Ken Levy could probably do it with about 18 lines of code).