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