>The concept is that this feature would let VFP developers design and code programs virtually exactly like they do today but VFP would, internally, pass the actual command to its 'server', perform all of the required I/O processing in that 'server', and return the resulting data to be made available to the program exactly as if the command had executed within the program.

Why not use Web Services to do this? This is exactly what Web Services and .NET are, why should VFP play its own, completely different game, when Web Services already have alot of momentum?

How would you handle transactions on these servers? How would you handle a transaction accross multiple VFP Servers? There's alot of stuff to implement here. Meanwhile, Web Services has this all figured out.

>My hot-button is data security. The 'server' component(s) could be located in a secure room with UPS power and managed by IT professionals, and since it could be arranged that all updating would actually be done on the 'server' then the incidence of damaged or corrupted tables would virtually disappear.

You could also use OLE-DB or maybe a secure DCOM component... or maybe... Soap and Web Services!