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

  • Article

Symptom:

=========

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.

Cause:

=========

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(https://support.microsoft.com/kb/983246):

"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.

Solution:

========

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

https://support.microsoft.com/kb/2517589

Comments

  • Anonymous
    January 01, 2003
    Thanks Sheng Jiang for the KB!

  • Anonymous
    March 17, 2011
    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.

  • Anonymous
    March 22, 2011
    This is a most unfortunate situation. This will be a big deal for lots (and lots) of developers.

  • Anonymous
    April 02, 2011
    The comment has been removed

  • Anonymous
    April 02, 2011
    Easy fix.  Uninstall Win7 sp1.  All is good.

  • Anonymous
    April 02, 2011
    The comment has been removed

  • Anonymous
    April 03, 2011
    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...

  • Anonymous
    May 13, 2011
    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.

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

  • Anonymous
    June 29, 2011
    I tried all the suggested workarounds, but only uninstalling SP1 works!!

  • Anonymous
    May 30, 2012
    The comment has been removed