Great analysis Erik...

Yea... it appears XML is very flexible. But, for large amounts of data, I wonder how efficient it is then...It is interesting with the SOAP stuff going on now. (http://www.develop.com/soap) It is funny because YAG was doing this stuff at the VFP devcon in San Diego 2 years ago...

With respect to ADO, I am not sure there the two calls come in. Bascially, I can invoke a method that returns a disconnected Recordset. Sure, I have to query the interface, invoke methods and such. But, I need to do the same thing with XML parser.

Both definitely have their place....

Thank you for giving me something to think about here.....


>>>., XML might be a better choise for this- I recommend you download Rick Strahl's wwXML class from www.west-wind.com.
>>
>>Interesting question..... XML vs. ADO for passing data around...
>>
>
>XML lends itself nicely to passing MetaData with the data. Say I've got a calling routine that is supposed to fetch data from a server and store it to a file with predetermined name (this is a single, very basic example), with XML, I can return the name of the file it should be saved to right along with the data. With ADO, you'd be doing 2 calls, or left with some other method. That still separates data from metadata. I'm sure you can think of a ton of other uses for metadata going with the data. With ADO, you're tied to the fields in the table and the structure information embedded in the recordset (unless there is a set of functionality in ADO that I am not aware of- I'm sure you could tell me.) With the advent of schemas, XML also has as much built in typing and validation as any other document type.
>
>Also, XML can be later passed across platforms, through http, or saved to a file that does not require a specific parser to make use of. (I know ADO can persist recordsets, but it takes an ADO recordset object to get it back).