Hi Cetin,

I don't know what exact test you've done and I don't have to .NET framework up and running here, but can you tell me how fast my solution runs compared the ones you've tested ? I'm just curious.
IMO, the main disadvantage of VFP is, is that it is interpretated, however it's advantage is that it has a very large set of powerfull commands that do complex algorithms in just one interpretation call. Hence, I'd like to know how the TEXTMERGE command performs in this case.

I've done some benchmarks, and this came as the fastest I could think off.

=AFIELDS(laFields, "Testcursor")
StartTime = SECONDS()

cString = "<CLIENT>"
FOR nT = 1 TO ALEN(laFields,1)
	cString = cString +  "<"+laFields(nT,1)+">%%"+laFields(nT,1)+"%%<\"+laFields(nT,1)+">"
ENDFOR
cString = cString + "\<CLIENT>"

SET TEXTMERGE DELIMITERS TO "%%","%%"
SET TEXTMERGE TO cXml
SET TEXTMERGE ON 

\<TEST>
SCAN
	TEXTMERGE(cString,.T.)
ENDSCAN
\\</TEST>

SET TEXTMERGE OFF
SET TEXTMERGE TO
SET CONSOLE ON


cXml = FILETOSTR("cxml.txt")
?SECONDS() - StartTime

Thanks.

Walter,

>I also touched to C# code to my knowledge for a faster C# code :
>

>public static void myTest()
>{
>	//Use Local FoxDB with lots of data
>	string strCon = "Provider=VFPOLEDB.1;Data Source=c:\\myPath";
>	string strSQL = "SELECT * FROM TestCursor";
>
>	//Start time
>	DateTime StartTime = DateTime.Now;
>	OleDbConnection cn = new OleDbConnection(strCon) ;
>	cn.Open();
>	OleDbCommand cmd = new OleDbCommand(strSQL,cn);
>	OleDbDataReader rdr = cmd.ExecuteReader(CommandBehavior.SequentialAccess);
>
>	TextWriter wr = new StreamWriter("c:\\myPath\\output.xml");
>	wr.WriteLine("<Test>");
>
>	//Build XML Result
>
>	StringBuilder rowString = new StringBuilder();
>	rowString.Append("\t<CLIENT>\n");
>	for (int cl=0;cl < rdr.FieldCount;cl++)
>	{
>		rowString.Append("\t\t<" +
>			rdr.GetName(cl) + ">{" +
>			cl.ToString() + "}</" +
>			rdr.GetName(cl) + ">\n") ;
>	}
>	rowString.Append("\t<CLIENT>");
>	string strRow = rowString.ToString();
>	object[] rowData = new object[rdr.FieldCount];
>
>	while (rdr.Read())
>	{
>		rdr.GetValues(rowData);
>		wr.WriteLine(strRow,rowData);
>	}
>	wr.WriteLine("</Test>");
>	wr.Close();
>	rdr.Close();
>        cn.Close();
>	Console.WriteLine(DateTime.Now-StartTime) ;
>}
>

This was exceptionally faster than original version - 17-18 secs. Still far away from VFP's 7-9 secs.
>
>The main reason VFP is being so fast was on data part as I could test. VFP was making the data ready in less than a second vs C# needed at least 11 secs just for the data (tried that with both a single cursor filling and an empty rdr.Read() loop). If we subtract timing lost on data getting this version does string portion in about 6-7secs which is almost the same timing as VFP's.
>
>But yet again on my part :)
>I wouldn't take a language/tool just with a few tests and I actually don't believe any developer might be using a single language/tool for all of her/his application needs. It's a developer's art to mix languages/tools for their best parts no matter it's directly supported via say CLR or COM or anything like that. I was mixing them in DOS days and would never stop doing so :)
>OTOH I wouldn't look into sayings 'Why not a VFP.NET' cold. IMHO they're fairly right in asking that. VB.NET and VC#.NET is not there to match and an another language is needed IMHO. But there are experts in the first 1-2 years and they should know better :) I must be dreaming thinking VFP.NET is possible just by reading inside architecture of .NET.
>(I didn't try a C++ version as MS claims all languages are created equal - some are created more equal we know anyways. I really wonder at times if they slowed down the C just to make show VB fast:)
>Cetin