>>These routines have been around before, but were written in VFP. The DLL is >>written in VC++, so it is VERY fast.

From my testing the VFPCOM's conversion to/from ADO recordset and VFP cursors is a factor of 100 time faster than dedicated VFP code (written specifically for the table structure, not Ken's generic converter).

I would not call the conversion "VERY fast", I would say that it's "Not quite as SLOW". For example, I execute a query via ADO and return 37,000 records in 5 seconds (that is 3.4 Meg of data tranfered over network plus SQL execution time). It then takes 51 seconds to convert that data from ADO recordset to VFP cursor using VFPCOM. Yes thats faster than the 540 seconds the hard coded converter took but this is still is not an acceptable solution.

This is just a patch for VFP not being able to directly access ADO recordsets with the same abilities as cursors and views, data binding to objects such as grids and use VFP's powerful native commands on the recordset. I realize that all this is not likely to happen.
-so-
For my wish list how about enabling VFP's remote view technology to be able to use the OLE DB interface along with ODBC? That alone would eliminate my need to use ADO from VFP.

On a positive note: BindEvents( ) - Cool!

Regards,
Mike