Compartir a través de

A Better solution for the Windows 7 SP1 ADO GUID changes

  • Artículo

UPDATE: This fix was published in mid-February as https://support.microsoft.com/kb/2640696 . We are still working on fine-tuning all of the documentation so that everything points to the appropriate places, but the binaries are already available. The fixes for Windows 7 and Windows 2008 R2 and publically available. Fixes for other OSes are also available, but you will need to open up a support case to request them.

If you are still using ADO in some of your code and tried to upgrade your build machine to Windows 7 SP1, you probably ran into the fact that you cannot run code recompiled on Windows 7 SP1 on downlevel OSes unless you modify your references to point to the backward compatible type libraries from https://support.microsoft.com/kb/2517589. Unfortunately, the solution does not work in several scenarios of which the biggest is Visual Basic for Applications (VBA).

The GUID change itself was not really the big problem – in fact, if you have been developing against MDAC/WDAC for a while you probably remember the days when applications would only run on the MDAC version that it was compiled on or higher. When we stopped revisioning MDAC around the Windows 2003 SP2 days, the problem pretty much went away. Until recently…

What happened is that we realized that some of our ADO APIs used platform dependent data types. This caused problems when 64-bit applications tried to consume these platform dependent data types and the caller’s data type did not match that of the callee. https://support.microsoft.com/kb/983246 discusses a scenario where a VBA macro runs into this exact problem. Unfortunately, we drastically underestimated the number of customers who were recompiling ADO applications on Windows 7 SP1. Even worse, when I say drastically, I really mean DRASTICALLY.

As soon as we realized the magnitude of the problem, we started scrambling to come up with a better solution. At this point, though, our significantly less than ideal first attempt had compounded the problem because it had the potential to spread the changed GUIDs to downlevel OSes. At this point, we made the painful decision to pull https://support.microsoft.com/kb/983246. Yes – we recognized that it would leave some scenarios like VBA without a workable solution, but we deemed that a better option than continuing to spread the modified GUIDs. Although not ideal, our standing recommendations were to use either the backward compatible libraries from https://support.microsoft.com/kb/2517589 or to compile on Windows 7 RTM. While not covering every scenario, it covered the bulk of them and was the best option we could provide without massive re-architecting.

Now, I am happy to announce that we are coming out with a much better solution. We are going to do the following:

  1. Ship the 6.0 type library from Windows 7 RTM via the new type library file msado60.tlb.  This will ship for multiple platforms.
  2. Ship a new 6.1 type library (which contains both new and deprecated interfaces) and embed it inside the msado15.dll
  3. Revert back all 2.x type libraries to what they looked like in Windows 7 RTM.

Therefore, the 2.x and 6.0 type libraries can be used for backward compatible purposes, and the 6.1 type library can be used for 64-bit VBA solutions. If you find yourself in the enviable place of not having to do any downlevel OS support, you can migrate entirely to the 6.1 type library even for your non-VBA applications.

Although you can see this fix in action in the Windows 8 Preview we shipped in September, we won’t be able to deliver the Windows 7 SP1 fix until early next year. As you can imagine, we are checking and re-checking everything because we completely understand that the only thing worse than no fix at this point would be another incomplete fix that requires yet another direction shift and another significant delay. Also, we are hard at working making sure some other known issues with the Windows 7 SP1 WDAC build get addressed with this fix as well. These are as follows:

We are still working hard to try to deliver this fix even sooner than early next year, but at this point I am not making any promises for an earlier delivery.

Comments

  • Anonymous
    November 01, 2011
    Thanks for this article which explains clearly the problem appearing in your link towards the SQL Server Data Access Forum. ADO and ADODB have disappeared in my own use since the release of VS 2003 , but i have kept the link about your "paper" just in case that i see a new thread about this problem in one of my best-prefered forums

  • Anonymous
    January 21, 2012
    Sadly unless the 6.1 typelib is somehow marked to prevent its use in 32-bit development this problem will re-occur over and over again.  Developer forums are chock full of Kasual Koders asking about this compatibility break over and over and over again.  Since they seldom read any docs and don't keep up on changes they are likely to see 6.1 and say "how spiffy and new" and select it.  Boom.

  • Anonymous
    January 24, 2012
    Just got pointed at this post from the ongoing forum thread [ social.msdn.microsoft.com/.../280de88a-77dd-455e-9797-b28928206e38 ]. It's great to see someone not only acknowledging the problem but also emphasising the impact it had on customers. Look forward to having a chance to test the fix (and to being able to finally update our dev machines to SP1) soon. Thank you :)

  • Anonymous
    February 02, 2012
    The comment has been removed

  • Anonymous
    February 06, 2012
    Thank you for admitting there is a huge problem, and working on a fix.  Please notify me when the fix is available. -Will will@senecatechnologies.com.

  • Anonymous
    April 21, 2012
    The comment has been removed

  • Anonymous
    June 27, 2012
    It's mid-"next year" now... so... we can find these wonderful, new, fix-all DLLs... where exactly?

  • Anonymous
    July 19, 2012
    Is this resolved yet?  If so, where?  Thanks.

  • Anonymous
    July 27, 2012
    Next year = whatever this year is + 1, I guess.

  • Anonymous
    August 21, 2012
    Any ideas why a W7SP1-compiled project with 6.0 doesn't work/isn't available (object not found) on XP SP3 machines, but 2.8 does? I thought 6.0 was supposed to be backward compatible...

  • Anonymous
    August 27, 2012
    Has this fix to Win7 SP1 been released?

  • Anonymous
    August 27, 2012
    look at the top of the page and you get a link to an update ;) support.microsoft.com/.../2640696

  • Anonymous
    March 05, 2014
    It’s  superb blog please  go through this url and solve your query . We provide Best online Services.check this site . <a href=windows7support.blogspot.in/.../fix-windows-7-error-1068.html> Fix Windows 7 Error 1068</a> Thank you Aalia lyon

  • Anonymous
    June 26, 2014
    The comment has been removed