Josh,

Thanks for that. I'm really looking for native VFP functionality though. I could do what I want with ODBC too (I believe) but I want the efficiency and power of VFP-to-VFP and not some other gunk.

On the bigger issue. . . now that I have had a chance to digest the fine reportage by UT members acting in that capacity, as well as having read some of the other comments offered here, I will NOW say that VFP looks like a good and reasonable delivery!

My main reason for saying so is that much of the work seems to have been directed at making VFP more straightforward for the newer adherent, and this truly was/is a badly needed objective. I've always felt that lots of purchasers put it aside after trying and failing, so if things are clearer and easier, then that is a BIG plus.

I hope that they went the full distance on this issue, though, and vastly improved the DOCUMENTATION too. Easier/simpler/clearer ain't really so if the docs retain their ambiguity and omissions.

Cheers,

Jim N

>Using ADO, a VFP automation server can return an ADO reccordset to a client.
>
>Josh
>
>>I have 1 really BIG one and lots of little ones (which surelt matter too). And the UT has a nice big list that anyone can reference and that MS is said to review.
>>
>>My BIG one. . .
>>
>>For VFP Automation Servers to be able to accept SQL statements from a client and to return the results set to the client.
>>In fact, I really want it to go further - for the Server to do *any* I/O command on behalf of the client (if I so choose) and have it return the correct information in the correct 'format', along with any statuses (like EOF etc.)
>>
>>Cheers,
>>Jim N