Hi Cetin. Yes I suspected this since we then split data retrieval and data convertion to xml into what, imo, are more logical and optimized operations. But as you say, a true comparison needs to optimize tests in both languages.

In any case I think the comparison between C# and VFP is not meaningful since it ignores the purpose to which a langauge is to be used, ie it ignores using the "right tool for the job approach".

Thanks for your comments and feedback.

Regards,


>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?
>>