If this is for one time data transfer then I don't think that performance should be an issue. Especially since generating the data should be fast - it's the reading of XML back into data that's generally slow because of the DOM access.

But for back and forth data transfers XML data should not be enormously large. If you do need to shuttle lots of data, it's better to break it up into smaller chunks and send that or do atomic updates. That way the DOM tree stays small and performance is much better.

+++ Rick ---

>thanks Rick,
>i am getting ready for my retirement at the end of this year. So one of my apps here at the state of Connecticut is being rewritten in c# and sqlserver by a vendor not familiar with VFP
>so I did xmltocursor to hand over the date to them
>
>is there a better way??
>
>Peter
>
>
>>Don't create gynormous XML documents. :-) Seriously that's not what XML is for. If you need to package large data tables or results, run them to DBF and then zip up and unpack the files. You get smaller files and much more performant operation.
>>
>>As Sergey pointed out CursorToXml() is simple because it just creates linear output one record at a time. However, the reverse uses the XML DOM which has to load the entire XML into memory (which can be very slow by itself as it build the DOM tree) and then has to parse through the XML document.
>>
>>
>>
>>+++ Rick ---
>>
>>
>>
>>>why is xmltocursor so much slower that cursortoxml???
>>>
>>>what can I do to speed it up ???
>>>
>>>the conversion to xml takes a few seconds, the revers days!!!!!
>>>
>>>
>>>Peter