Hi Mark,

I agree that's a very likely scenario.
In fact it was exactly that technique that Microsoft used to keep Windows support on OS/2 (rel.2, the best OS ever made) breaking all the time.

But I do have something in the back of my mind that should, in my opinion, should prevent such problems and I wonder why it wasn't used here...

A defined specification of OLE - and we're talking VFP's new OLEDB Provider here - is full backward support for "interface" protocols. If a new3 version of some OLE tool changes the interface specifications, the newer version must be given a new "ID" AND the old "ID" and its interface are to be preserved so they continue to function as before.

Now the problem you've hit may not technically be an "interface specification", but its "spirit" is the same in that the older code using, by definition, the older interface SHOULD CONTINUE TO WORK.
In this case the "interface" appears to continue to work, yet the whole code as a package does not. I'd call that a 'violation' of the OLE specification that NEEDS FIXING.

Let's hope they do!!!



>I understand what you are saying... but that solution assumes you have the source code for all apps in use. Just for fun, consider this scenario: Lets assume that you install a commercial app (with no source code) on your server, and assume that the app uses VFP OLEDB and was developed with the OLEDB driver associated with V8 of VFP. Later, on the same server you install another vendor's app (a completely different app, not a replacement) or maybe install your company's own app, and it either requires or happens to also install OLEDB for VFP9, thus upgrading the V8 driver. I can see this happening pretty easily with web apps that use ASP and OLEDB or something similar. Suddenly the legacy app breaks and you are stuck with a mutually incompatible version conflict because there's nothing you can do about the app(s) for which you don't have source code. It's not the first vendor's fault that you installed a new DLL that broke his perfectly working code.
>
>
>>VFP9 is backward compatible in that area with SET ENGINEBEHAVIOR 80. Check Re: Using VFPOleDB and Set EngineBehavior Thread #1052518 Message #1052550
>>
>>>Thanks for the enlightenment. I don't like it but I guess I'll have to live with it. Philosophically I take exception to new releases of support libraries of any type (including OLEDB) that by default and in the absence of explicit counter measures, will break existing applications that depend on those libraries. i.e., Existing code should always be backward compatible.
>>>
>>>In my $0.02 of an opinion, I think it would be better to require the issuing of an explicit SET command to invoke such a new set of behaviors (assuming they are app-breakers for legacy apps). Thus existing apps would live on in bliss and new apps can take advantage of the new behaviors. Another option would be to have a separate DLL that was registered under a slightly different moniker, so then you could use a version-explicit connection string, i.e., something like "Provider=VFP9OLEDB;" rather than generic "Provider=VFPOLEDB;". Meanwhile, existing apps that use "Provider=VFPOLEDB;" would never need to know about the new/separate DLL.
>>>