Evan,

Server-lite. . . yes and no.

What I really want is X-base-in-a-server, sort-of.

I want an intelligent back-end for VFP, so my front'ends can ask for data and get that data and specify change to that data and have the server *do* the actual changing.
BUT I want this in the "native" VFP command language, so *IF* I want to read table-X and table-X is *NOT* in use in my machine, then my VFP-server can be asked if it knows anything about it, and if it does it *automatically* provides the data, as if it came from the local apps machine.

Not quite a server-lite. Possibly a X-base-server-simple.

Cheers,
Jim N

>>1) What I (really) want:
>>
>>I want that I can "communicate" to another VFP **without** doing anything special in programming, along the lines of *ANY* VFP I/O command from SQL to SKIP to whatever one you want, in such a way that *IF* the current VFP does *NOT* have the record/table/file in question, then it will "know" of other VFPs that are running and it will send the "command" off to them (one at a time, let's say) until either the command is executed or all have returned 'sorry, can't do it'.
>>
>>Let me try that again. . . If the VFP in which the I/O command is originally issued cannot deliver (cause it does't recognize the table as open or some such), then it would be aware of other active VFPs and it would pass the command on to them to execute, and the one which does returns the info/result to the originator so that the originator keeps on truckin.
>>
>>What this would let me do, for instance, is to have a ALL-VFP application where the front-end was on terminals all over the place but the back-ENDS (note the "s") could be in a highly secure and power protected environment. This would give me *most* of the benefits of an expensive SQL-server type facility ALL BY VFP and with the speed and simplicity of VFP.
>>
>
>Jim,
>
>I had to read your message a few times, but what it sounds like you want is some kind of SQL Server lite that is built into VFP. N'est pas?