Actually I tried it out of curiosity too :) It's +/- 1 secs better (8-9 secs).
I thought in turn someone would come up and say, well what if this was not for XMLing, or what if C# also used XML class and serializing instead of massaging a string as records are encountered (say a parser).
In my version, there is no update to a string variable. I think that's where VFP really sucks. Directly using lowlevel or VFP's copy to or building XMLed string directly to SQL itself keeps C# in dust :) (even C# version which I thought to be the fastest can't keep up. When it could just only loop the data w/o doing a single thing -like and empty scan..endscan- VFP finishes its stringifying).
If I weren't satisfied with pure VFP solution I could take it one step further and utilize VFP's FLL capability with the more created equal C++ :)
Cetin

>Hi Cetin,
>
>Pardon my ignorance but instead of continually updating (adding to) a string memory variable could extracting the data to a temp cursor first and then using cursortoxml() be faster?
>
>>Hi Walter,
>>I tried your version and with repeated calls it has timing around 17-26 secs.
>>My test is very simple. TestCursor is a simple cursor with few fields of different datatypes and 200K recs. Select into part just selects all records (no filter clause where VFP would show itself more).
>>VFP's being interpreted seems to be as a disadvantage at first but after .NET I doubt if interpreting is a bad way or not :)
>>Cetin
>>