>2. The VFP 7 OLEDB provider doesn't even work correctly with ADO.Net. We have been promised a fix for about a year. I don't know whether the provider with VFP 8 addresses the problems. There are some bad problems (acknowledged issues that have been discussed elsewhere) where you are unable to update VFP data with ADO.Net. This is not due to a problem with ADO.net. There is an acknowledged problem with VFP's ole db provider.

The VFP 8.0 OLE-DB provider (beta) was released with the VFP 8.0 public beta and it fixes these issues. Has VS even been out for a year? How can a fix to work with a product that hasn't been out for a year have been promised for a year?

>The fact is, I can think of no good excuse for VFP 7's oledb provider to not work with ADO.Net. They were both developed by MS. MS had been working on .Net for 3 years at the time that VFP 7, and the oledb provider were released.

Perhaps cause the VFP 7 OLE-DB provider came out when .Net was in Beta 1. Then, MS changed the spec and by then it was too late.

>3. VFP 8 included a new Cursor Adapter Class that should make working with native cursors, ODBC datasources, and ADO data sources homogenous. I notice that ADO.Net is missing from the list. How can we claim "excellent integration" when this new data feature completely excludes the preferred means of data access in .Net?

ADO.Net is a .Net component. You still use ADO (COM) to access OLE-DB providers with VFP.

>4. VFP 8 doesn't emit managed code. .Net is all about the CLR and managed code execution. VFP 8 doesn't emit a scrap of managed code.

VFP has been using managed code and a runtime for years. Back then, everyone trashed it. "Not a native more compiler, etc." Now you want them to run against a runtime that they didn't write.

BOb