Very well said!

I think it falls on what the goal is and whether the goal is short-term or long-term. IMO, I don't think a goal exists that encourages non-VFP developers to work with VFP. If there was, I think the philosophy you have articulated here would have been followed. Nonetheless, there is a lot of VFP data out there and IMO, it is important to provide people the ability to access that data. For the most part, that problem is already solved with the ODBC Driver. In some respects - this is Much Ado About Nothing!

The goal as I see it and has been stated by Ken, is upgrades and ironically, keeping the customer happy. VFP customers asked for an OLE-DB Provider and low and behold, the customers got it. Whether it will be used or not, that is another issue.

The question is whether the customers wanted an OLE-DB Provider so they could actually use it or was it desired because everybody else had one. By not having a native OLE-DB provider, was VFP's position in the world somehow de-legitimitized? I don't think so.

IMO, something should be done right or it is not worth doing. Comparing the VFP ODBC Driver and the VFP OLE-DB Provider, I don't see big differences. If anything, the VFP ODBC Driver may be better because it is more straightforward when adding data to a recordset. You have to jump through through a few hoops to get it to work right in the VFP OLE-DB Provider. I am sure there is better support for somethings in OLE-DB through the provider. But for the most part, you can do everything you need to do with the ODBC Driver. And, for those times when you do run into problems, the question is not whether you should be using the VFP ODBC Driver or VFP OLE-DB Provider. Rather, the question is whether you should be using VFP or SQL Server...