Microsoft Reduce Customer Effort Center

Our team drives product feedback based on solid data, it drives proactive issue prevention and ultimately, drives improvements around products based on customer feedback.

Changes in MDAC ADODB COM components in Windows 7 Service Pack 1

Changes in MDAC ADODB COM components in Windows 7 Service Pack 1

  • Comments 11
  • Likes



On a computer with Windows 7 SP1 installed, you develop and build your application that is using ADO for database access, you find the application doesn't run on the Windows XP, Windows Vista, Windows 7 without SP1. But it runs well on Windows 7 with SP1.



There is a by design change in ADO in Windows 7 SP1 that interfaces have new GUIDs.

The reason of this change is mentioned in KB983246(

"Some ADO APIs are platform dependent in ADO 2.7 and later versions. On 64-bit versions of Windows, these ADO APIs process arguments by using a 64-bit data type (such as the LONGLONG data type). However, applications that use these APIs still use the LONG data type. Therefore, you receive a "Type Mismatch" error message when you try to run the macro."

The interfaces with new GUIDs (in Windows 7 SP1) don't have such issue.

This change causes a break that if your application is re-compiled on Windows 7 SP1 and it uses early binding to ADO, it probably doesn't work on down-level OSes, such as Windows 7 RTM, Vista, etc. Please note that this break only happens when the application is re-compiled. Existing applications should run on Windows 7 SP1 without any problems.



If you have to re-compile your application on SP1, there are several solutions:

  1. Request a package of KB983246 and install it on your customers' machines. Re-compiled application should work after the package is installed.
  2. Re-write your application to use later binding to ADO, or use interfaces with name xxx_deprecated.
  3. Keep an old version of ADO typelib (i.e., msado28.tlb) (copy from Windows 7 RTM), then compile your application with the old typelib, instead of the one in your system.
  • Open Regedit and locate the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}
  • Right click, Permissions, Advanced, Owner, Change owner to Administrators, Click OK, OK
  • Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 -u "%CommonProgramFiles(x86)%\system\ado\msado28.tlb"
  • Copy msado28.tlb from Win7 RTM/Win2008R2 RTM to your local machine, note the folder for the next step.
  • Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "{path}\msado28.tlb"

Edit: please refer to the knowledge base article kb2517589

  • please refer to the knowledge base article kb2517589 An ADO application that is re-compiled on a Windows 7 Service Pack 1-based computer does not run on down-level operating systems for more walkarounds.

  • This is a most unfortunate situation. This will be a big deal for lots (and lots) of developers.

  • Thanks Sheng Jiang for the KB!

  • This is a big deal.  Let me see - have 100+ users run a hot fix to correct the problem on my Win7 compiler.  What's wrong with that?

  • Easy fix.  Uninstall Win7 sp1.  All is good.

  • I Think that this produce a high level cost for the developers and problems with the clients....and I´m think....the next SP...don´t let me run my several VB6 applications???...Think better please...we are the developers that are migrating our app to .net, don´t introduce ilogic problems in the middle!!

  • Ab is right; I have several VB6 projects that I am moving to VB2010 and all my new projects are being developed in .Net; however since "moving" means "rewrite from scratch" my hands are full - i don't need "distractions" like this one...

  • I should not have to choose between keeping my development boxes up-to-date and being able to deliver working code to my customers.

    Pushing this change without more advance warning was an appalling lapse in judgment.

  • Nice one Microsoft, you've broken one of the cardinal rules of backwards compatibility.

  • I tried all the suggested workarounds, but only uninstalling SP1 works!!

  • This sucks. Microsoft has done it again!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment