These are all valid points you bring up. Of course, one noteable exception to the supported command list is CreateObject. Therefore, if you encapsulate your logic in classes, you are SOL.

IMO, the issue is a real vs perceived threat. I contend that if you gave VFP away, the developer base would not grow. As for people that pirate the software, they will do so regardless of what the vendor does. Finally, if a developer can distribute the OLE-DB Provider on a royalty free basis, I ask then: "What is the difference?"

Ken cleared the issue up as being one that encourages upgrades. The protecting of an intellectual property interest is not the fundamental motivator here.

I contend that if MS gave away the OLE-DB Provider, people would not all of a sudden decide to eschew a purchase/upgrade in favor of trying to build an application using the OLE-DB Provider. That argument is without merit. The IDE tools and everything else the main environment offers.

I guess my argument is not what the provider can or cannot do. My argument is that if you give the provider away, the people that would upgrade to 7 would be unaffected.

Once could also say that in this case, the tight coupling between the langauge runtime and the database is more of a hinderance than a help. Perhaps the OLE-DB Provider is overloaded. Let's remember that VFP is a file-based database engine. What would be done in stored procedures, most people probably accomplish in middle tier components so that one is not tied to a particular back-end. The OLE-DB provider needs to perform the CRUD operations and the SQL DDL as well. The language support in the ODBC Driver was fine. The goal I thought was to make VFP fit better in the ADO/OLE-DB Space. I seriously question whether the additional command support, because it is tied to DBC Stored Procedures, is something that will be that widely used...