>The difference is that returning the DataSet itself returns an object and if one attempts to use it from any other client other than a .NET client, one needs to use the XMLDOM to parse it out correctly. Thinking of it in these terms, getting a DataSet from a WebService and then trying to use it in VFP with XMLTOCURSOR(), you would not be able to do it. You have to go through all that crap of using the XMLDOM to parse it out correctly before you can get the data out of it. (Or, as I'm sure Rick may jump in here and tell everyone <g>) ... you can use Rick's wwXML for easier parsing. Regardless, the point is that you can't utilize that XML without doing extra stuff to it.

Well, yes and no <g>...

The difference is just that you return a string vs. an object graph in XML. The fact that VFP's XMLTOCURSOR() understands the result of GetXml() is incidental. See if you do:

StringWrite loWriter = new StringWriter();
ds.WriteXml( loWriter,XmlWriteMode.WriteSchema loDs.WriteXml )

return loWriter.ToString();

from your Web service as a string you will have exactly the same issue with conversion.

There is a difference how the string travels over the wire compared to the DataSet: The string is encoded into XML save text (ie. all the angle tags are converted to markup chars), whereas the data set travels as an embedded XML entity. So in terms of size and serialization the latter is more efficient because it doesn't need to encode.

How that is picked up on the other end differs then, but assuming you don't have a highlevel tool either way you'd have to use a parser to read the data. Access to the data would be different too: With the string you'd have to open the parser to read the string, then load the resultant string into another parser instance to actually parse.

The point is there's more overhead with passing a string back and forth. OTOH, strings can be consumed and understood by any SOAP client - objects not so much. But most tools will allow you to retrieve the raw XML or a DOM node to get at the data as needed.


It really depends on how open your app needs to be. If you have other SOAP clients or even non soap clients they should be able to consuem the data either way even if they couldn't access an object as an object.

For the decision on that I would use the majority rule: If more than half of your users will use .Net to acccess the data then it's a pretty obvious choice to use something that's easy to them (ie. pass the dataset).