>>>>Doubtful. VFP's internal XML parsing is blazing fast. I'm not sure if they're using MSXML or not internally, but if they are they are low level early binding to it, which will be much faster than anything we can do with the late bound MSXML objects.
>>>
>>>Internally, XMLTOCURSOR uses MSXML, and CURSORTOXML parses it itself (at least I think it does; haven't actually looked at the code myself). This is would partially explain the speed difference between the two functions.
>>
>>If it's done manually you always have to worry about keeping up with XML standards - I'm well familiar with this since this is what wwXML does too. But export is considerably easier than import so using MSXML for importing is likely to be a requirement in order to deal with schemas/namespaces etc....

Not really - not for VFP anyway. The text reader is supposed to be very fast and for cursor parsing it's probably a good tool. But I wouldn't want to call into .Net (ie require the CLR around) just for doing XML conversions.

Also the XML Reader is non-validating (at least some of the classes anyway) and I'm not sure how this works with the various attributes of the cursor etc. I haven't played with it, so I can't say from first hand experience.

Personally, I don't send that much data around that the speed of any of the XML conversion routines have ever been a problem. If you're sending more than a few hundred k of data around one needs to rethink the application including potentially chunking up the data at least in a distributed environment.

The DOM model works fine on sizes around 1 meg and I've not seen degradation even on larger files but it can be resource intensive...

+++ Rick ---