Terry,

>Without VFP as the COM, the developer would have to use XOM on an ADO recorset and "build" the XML (AddNode/AddAttribute,etc)...

Or just bypass using COM at all and go .NET to backend database. This part of this voluminous and interesting discussion was about calling VFP COMs and whether they used a "pass through VFP cursor."

>... So I agree with you that NET is using XML - and that VFP's XMLToCursor and passthrough [DBF] cursors are alot easier than transcribing raw ADO to XML.

What I was addressing was that you have more options than just using SQL Passthrough -- maybe that's not what you mean when you say "pass through VFP cursor" but I can't think of anything else you might mean by that phrase, since you can't pass the VFP cursor anywhere outside of VFP without converting it first. :-)

>If that's what you're saying? IF your saying there is a new SQLEXE() argument that returns a rowset as XML - then I plead ignorance. But if you're not - then a DBF is in the stream - and a DBF is xBase!

You can get XML from SQL Server into VFP via HTTP if you set it up that way (virtual directory, template queries, etc).

The point of this sub-discussion (I thought) was whether or not you use xBase DML commands against a SQL Server backend and Martin was arguing that SQLEXEC is not an xBase DML command. What you do against the cursor or table that results from whatever actions to take to get the remote data can be xBase DML or something else including another SQL SELECT, a conversion to XML, or whatever...

... whcih is probably the best way to bring this little detour to an end.

Whatever... :-)