Hi Cetin,


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

This won't work with this approach since the and rely on the first and last recordnumber which can be skipped due to the for clause.

>(ignore new way of skinning the cat for lcFields:) Just there to show a new skinning, that part was the least contributing to timing) :

Yes, it does not make a lot of sense to do this low level. The time needed for building the string is nothing compared to the time needed to copy it to a file. Below my latest version with the CHR() function out of the field expressions. It seems to be the fastest it can get as I don't see new ways of speeding up the COPY TO command. The rest of the algorithm is insignificant (performance wise), at least for larger resultsets.

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)+">'+" + ;
			IIF(TYPE(FIELD(ix))$'CM', "TRIM("+FIELD(ix)+")", "Transform("+FIELD(ix)+")")+ ;
			"+'</"+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

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

Though it won't be fair to extrapolate this test to the whole .NET platform, it does illustrate that a local database engine can have significant advantages. The ommision of a local database engine therefore IMO is limiting the developer in the ways you can skin a cat.

Walter,