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



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_MACHINESOFTWAREWow6432NodeClassesTypeLib{2A75196C-D9EB-4129-B803-931327F72D5C}
  • Right click, Permissions, Advanced, Owner, Change owner to Administrators, Click OK, OK
  • Run C:WindowsMicrosoft.NETFrameworkv4.0.30319regtlibv12 -u "%CommonProgramFiles(x86)%systemadomsado28.tlb"
  • Copy msado28.tlb from Win7 RTM/Win2008R2 RTM to your local machine, note the folder for the next step.
  • Run C:WindowsMicrosoft.NETFrameworkv4.0.30319regtlibv12 "{path}msado28.tlb"

Edit: please refer to the knowledge base article kb2517589

Comments (11)
  1. danma_ says:

    Thanks Sheng Jiang for the KB!

  2. Sheng Jiang says:

    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.

  3. John West says:

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

  4. bill says:

    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?

  5. bill says:

    Easy fix.  Uninstall Win7 sp1.  All is good.

  6. Ab says:

    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!!

  7. Carlos C says:

    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…

  8. Duane Roelands says:

    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.

  9. Scion says:

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

  10. Rikisax says:

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

  11. Tingzab says:

    This sucks. Microsoft has done it again!

Comments are closed.

Skip to main content