Neil,

>Is there any chance that someone at Microsoft is aware of this aberrant behavior? This is of great concern to me. I bought into the .net framework because I thought I could continue to leverage my previous investment in VFP and use a common language (C#) to write all of my future applications for multiple platforms and devices. I was hoping to write new applications for my clients and take their existing vfp databases to new and exciting places.

Microsoft is aware of this...in fact, here is a Knowledge Base article "PRB: OLE DB Provider for Visual FoxPro Does Not Work with OleDbCommandBuilder or DataAdapter Wizard":

http://support.microsoft.com/?id=316548

This is unfortunate for developers using VFP data. From what I've seen, the problem lies more with VFP's inability to work with the Data Adapter Wizard rather than the Command Builder (although there definitely are issues here too).

To show you what I mean, try the following:

1. Create a custom Order Detail data access object subclassed from mmDataAccessOleDb...but don't run the Data Adapter wizard against it.

Remember, the reason you had to create a custom SQL Server data access object is because the SQL Server Northwind database table is named "Order Detail" (with a space), and the Command Builder can't handle this (oddly enough). In contrast, the VFP Northwind database table is named "orderdetail" so you don't necessarily need to create a custom data access class...a generic subclass of mmDataAccessOleDb may do.

2. In your Order Detail business object, override the CreateDataAccessObject method and instantiate the custom Order detail data access object as described in the MM .NET Dev Guide.

3. Run your application and see if it works

By default, unless you specify otherwise, MM .NET will use the .NET OLE DB Command Builder to dynamically generate the INSERT/UPDATE/DELETE commands for the Order Detail data access object. My guess is that this will work for you even though the Data Adapter Wizard did not.

>You and I have had a common basis for discussions up to this point, in that we are working with the same documents, code and database. How can I now venture off into my own little development world, utilizing a data provider, which is not ready for prime time?

Although I have known for some time that the VFP OLE DB provider wasn't quite up to snuff, my hope was that the new version released in August would have resolved these problems...unfortunately, although it fixed some things, it didn't fix them all.

>Perhaps we can share this thread with the folks that support the VFP Data provider?

I will! The Fox team does its best to determine what enhancements/fixes are most important to developers, so although I will personally mention something, the more people that raise this issue, the better!

Regards,