>Hi Cetin,
>
>O.K. now it is clear to me. Thanks for pointing that out. I've looked at your code and in my testing it was a little faster than the textmerge approach. However, you did come up with an interesting mechnism to use a fairly unused and unknow VFP feature of SET FIELDS in combination of functions in columns. The only thing that was puzzling me was the inefficient way you added the tags. I did come with the following to circumvent that one.
>
>

LOCAL cChar, cFields, cFile, nReccount, nStartTime, ix
>
>SELECT * FROM h:\ids5\dbfs\t_tanklayout INTO CURSOR _tmpXML NOFILTER READWRITE
>
>nReccount = RECCOUNT()
>cFile = SYS(2015)+'.tmp'
>nStartTime=SECONDS()
>cChar=CHR(13)
>
>cFields = "fb=IIF(RECNO() = 1,'<TEST>'+CHR(13),'')+CHR(9)+'<CLIENT>',"
>FOR ix=1 TO  FCOUNT()
>	IF !TYPE(FIELD(ix))$'GM'
>		cFields = cFields + "f"+ALLTRIM(STR(ix))+"=CHR(9)+CHR(9)+'<"+FIELD(ix)+">'+"
>		cFields = cFields + IIF(TYPE(FIELD(ix))$'CM', FIELD(ix), "Transform("+FIELD(ix)+")")+"+"
>		cFields = cFields + "'</"+FIELD(ix)+">',"
>	ENDIF
>ENDFOR
>cFields = cFields + "F"+ALLTRIM(STR(ix))+"=chr(9)+'</CLIENT>'+IIF(RECNO() = nReccount,CHR(13)+'</TEST>','')"
>
>SET FIELDS GLOBAL
>SET FIELDS TO &cFields
>COPY TO (cFile) TYPE DELIMITED WITH "" WITH CHARACTER &cChar
>SET FIELDS TO
>
>? SECONDS() - nStartTime
>
>MODIFY FILE (cFile)
>ERASE (cFile)
>RETURN

>
>I don't think it can be written much faster than this. Even the CURSORTOXML() function is not significantly faster than this.
>
>In the light of this discussion I think we can conclude that because of VFPs data engine you've got multiple tools to skin the cat. Exactly these kinds of mechanisms make VFP such a powerful language. There always seems to be another faster way of munging data. Again with .NET you've got not much other alternatives than iterating trough object collections... OUCH...
>
>Walter,

Hi Walter,
Yes VFP has got multiple ways to skin the cat :) With C# it might be possible to do it in faster ways too (say you had at least read access directly to file, bypassing OleDb or ODBC messaging - but the context was to compare data retrieval and a local engine power).
Talking about inefficency I added another 1.5 seconds of efficiency removing the chr(9) calls with directly putting the TABs in expressions and using VFP's data power to use the table directly with a for clause instead of SQL.
(ignore new way of skinning the cat for lcFields:) Just there to show a new skinning, that part was the least contributing to timing) :

StartTime=Seconds()
lcMyXML=ToXML('testcursor')
? Seconds() - StartTime

lcTemp = Sys(2015)+'.tmp'
Strtofile(m.lcMyXML,m.lcTemp)
Modify Command (m.lcTemp)
Erase (m.lcTemp)

Function ToXML
Lparameters tcCursorName, tcWhere
Local lcChar,lcTemp,lcXML,lcFields,ix,;
  lcFields, lnHandle, lcTempFields,lnSelect
lnSelect = Select()
lcChar=Chr(13)
lcTemp = Sys(2015)+'.tmp'
tcWhere = Iif(Empty(m.tcWhere),'',m.tcWhere)
Select 0
Use (tcCursorName) Again Alias _tmpXML

lcTempFields = Sys(2015)+'.tmp'
lnHandle = Fcreate(m.lcTempFields)
Fwrite(m.lnHandle,;
  "f0=IIF(RECNO() = 1,'<TEST>'+CHR(13)+'	<CLIENT>','	<CLIENT>'),")
For ix=1 To Fcount()
  If !Type(Field(m.ix))$'GM'
    Fwrite(m.lnHandle,"f"+Ltrim(Str(ix))+"='		<"+Field(ix)+">'+")
    Fwrite(m.lnHandle,Iif(Type(Field(ix))$'CM',;
      'Trim('+Field(ix)+')+',;
      'Transform('+Field(ix)+')+'))
    Fwrite(m.lnHandle,"'</"+Field(ix)+">',")
  Endif
Endfor
Fwrite(m.lnHandle,"f"+Ltrim(Str(m.ix)))
Fwrite(m.lnHandle,;
  "=Iif(Recno()=Reccount(),'	</CLIENT>'+Chr(13)+'</TEST>','	</CLIENT>')")
Fclose(m.lnHandle)
lcFields = Filetostr(m.lcTempFields)
Erase (m.lcTempFields)

Set Fields Global
Set Fields To &lcFields
Copy To (m.lcTemp) &tcWhere ;
  Type Delimited With "" With Character &lcChar
Use In '_tmpXML'
Set Fields To
Select (m.lnSelect)
lcXML = Filetostr(m.lcTemp)
Erase (m.lcTemp)
Return m.lcXML

So VFP sets its mark from 8 secs to just under 6.5 seconds vs C# 17-18secs :) Wish it was this fast and powerfull when it's something not data too :)
PS: This is not to make .NET guys angry and compete, we too use .NET, competing on such a narrow context wouldn't be fair at all.
Cetin