Thank you David,

I am not aware of a SQLEXEC() syntax that returns an XML. It returns a "cursor" that would be converted into XML.

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

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!

>Terry,
>
>>...But NET projects that use VFP COMs in the data tiers are probably using a pass through VFP cursor (that's a DBF!)...
>
>In most cases where .NET is calling a VFP COM and getting back some representation of a data row or collection of data rows (and not just a single value), the VFP COM object is querying either Fox tables or a backend database and converting the data into XML that can be read into a .NET DataSet.
>
>The conversion to XML can be done easily with XMLAdapter, CursorToXML, or with other tools like Rick's wwXML.
>
>When I say "the VFP COM object is querying..." that can actually mean any number of things that might involve issuing SQL SELECT against Fox tables, opening a local VIEW against Fox tables, issuing SQL SELECT against SQL Server or another ODBC source via Remote Views or SQL Passthrough, going against Fox or ODBC or ADO via CursorAdapter, or just USEing a Fox table (and setting a FILTER to limit the records). With any of those scenarios, you end up with a group of records in either a Table or Cursor, which then gets converted into XML that can be read into a .NET DataSet by the .NET application.
>
>So, it would not be always accurate to say the VFP COMs being called by .NET are using a "pass through VFP cursor," unless I'm misunderstanding what you meant by that.