>Sure I can, Evan. . .
>
>Sit back and get into DREAM mode.
>
>
>I'll do this in two parts - what I *want* and what I would *take*.
>
>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'.

Hi Jim,

Looks to me like you need to make each of your VFP apps into DDE Clients and Servers. Trust me, DDE is fast and cheap on memory usage. I have done it with two VFP apps talking to each other, a VFP app talking to a C++ program that talks to firmware which then sends responses to the C++ app which in return sends responses to the VFP app.

>
>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.
>
>2) What I would take:
>
>The capability to have *all* SQL commands, including VIEW-related stuff, passed on to ANOTHER VFP session, probably on another secure/protected machine and get the results back (or updates done) **AUTOMATICALLY** without the need for special programming to arrange so.
>I would accept that I had to have an "INI-type" file to "control" this, possibly to direct/limit the search for VFPs and also to restrict to certain tables. I would also accept that all tables in such a scheme had to be in DBCs.
>
>The objective would be similar in both cases, just that one would be far more general than the other.
>
>That's the dream, and I hope to see some steps toward that end in the next release! Else I'd be just as happy to have them release only fixes and improved docs.
>
>Cheers,
>
>Jim N
>
>
>>>Any mention at all of a VFP-to-VFP capability *WITHOUT* need for ODBC???
>>
>>Jim,
>>
>>Can you elaborate on this?