Kev,

I've not read every post in this thread yet, so if these points have already been made please forgive me.

First off why not use CursorToXML() to do the grunt work of generating the XML and then doing a couple of strtran()s to tweak the result as needed?

>I was actually more interested in the local-data performence, I think I may have to try something else, the string handling side of it I'm not too bothered about.

But the only thing you are timing is the string performance, there's nothing in your timed code section that really "qualifies" as local data enghine performance.

>I would be very interested in performance with the local data-engine, perhaps if you were to knock up some powerful local data-engine tests I might be able to try it in C# and potentially spot weaknesses in ADO.Net.

Both code fragments could be sped up significantly by hoisting invariant code out of the loops.

For example this fragment:

		lcXML = lcXML + "<" + laFields(f, 1) + ">" + ;

			"</" + laFields(f, 1) + ">"

recalculates the exact same result over and over for each row. You'd be much better off calculating these once and reusing them:

for i = 1 to alen( laFields, 1 )
   laFields[i,2] = "<" + laFields[i,1] + ">" && reuse these already allocated array locations
   lcFields[i,3] = "</" + laFields[i,1] + ">"
endfor

* then in the scan loop
   lcXML = lxXML + laFields[f,2] + ;

      laFields[f,3]

this hoists 4 redundant string concatenations out of the loop so instead of doing 7 you are doing 3. The "test." + laFields[] could also be hoisted out to save yet another concatenation.

The same optimization could be done in the C# code.