Article ID: 2517589 - Last Review: January 17, 2012 - Revision: 7.0

An ADO application does not run on down-level operating systems after you recompile it on a computer that is running Windows 7 SP 1 or Windows Server 2008 R2 SP 1 or that has KB983246 installed

System TipThis article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.
Caution ADO and ADO MD have not been fully tested in a Microsoft .NET Framework environment. They may cause intermittent issues, especially in service-based applications or in multithreaded applications. The techniques that are discussed in this article should only be used as a temporary measure during migration to ADO.NET. You should only use these techniques after you have conducted complete testing to make sure that there are no compatibility issues. Any issues that are caused by using ADO or ADO MD in this manner are unsupported. For more information, see the following article in the Microsoft Knowledge Base:
840667   (http://support.microsoft.com/kb/840667/ ) You receive unexpected errors when using ADO and ADO MD in a .NET Framework application

On This Page

Expand all | Collapse all

SYMPTOMS

Consider the following scenario. On a computer that is running Windows 7 Service Pack 1 (SP1) or Windows Server 2008 R2 SP 1 or that has KB9823246 installed, you recompile a Microsoft ActiveX Data Objects (ADO) application by using one of the following applications:
  • Microsoft Visual C++
  • Microsoft Visual Basic for Applications (VBA)
  • Microsoft Visual Basic 6
  • Microsoft .NET applications
In this scenario, you find that the application does not run on down-level operating systems. For example, it does not run on the release version of Windows 7, on Windows Vista, and on other earlier versions of Windows. Depending on your implementation, you also receive an error message that resembles one of the following. (You may receive other error messages.)

Error message 1
REGDB_E_CLASSNOTREG (0x80040154)
Error message 2
E_POINTER (0x80004003)
Error message 3
E_NOINTERFACE (0x80004002)
Error message 4
Unable to cast COM object of type 'System.__ComObject' to interface type 'ADODB.Connection'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{00001550-0000-0010-8000-00AA006D2EA4}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).”
The following Visual C++ code segment replicates this issue.
#import " msado15.dll" no_namespace rename("EOF","EndOfFile")
 
int main()
{
  CoInitialize(NULL);
  _ConnectionPtr pConnection = NULL;
     HRESULT hr = pConnection.CreateInstance(__uuidof(Connection)); //hr gets E_NOINTERFACE here
}
The following Visual Basic for Applications code segment replicates this issue.
Private Sub Form_Load()
 Dim Conn As New ADODB.Connection ‘Runtime error here: Class does not support Automation or does not support expected interface
End Sub
VBA Error:Run-time error '430': Class does not support Automation or does not support expected interface

Note Microsoft no longer supports the primary interop assembly for ADO and no longer supports Visual Basic 6. For more information about Visual Basic 6 supportability, visit the following MSDN webpage: For more information about the primary interop assembly for ADO supportability, click the following article number to view the article in the Microsoft Knowledge Base:
318559  (http://support.microsoft.com/kb/318559/ ) Using the primary interop assembly for ADO (ADODB) in Visual Studio .NET

CAUSE

This issue occurs because some ADO interfaces were changed in Windows 7 SP1 to be associated with new instance identifiers (IIDs). The older IID interfaces were assigned the following suffix:
_Deprecated
For example, the interface _Connection was updated as follows:
  • In Windows 7 and in earlier versions of Windows, the _Connection IID is 00000550-0000-0010-8000-00AA006D2EA4.
  • In Windows 7 SP1, the _Connection IID is 00001550-0000-0010-8000-00AA006D2EA4, and the IID for _Connection_Deprecated is 00000550-0000-0010-8000-00AA006D2EA4.
If your application uses early binding to _Connection, the new IID is stored in the application binary during compilation. This causes an error when the application runs on a down-level operating system because the IID does not exist.

Some ADO APIs are platform-dependent in ADO 2.7 and in 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.

WORKAROUND

To work around this issue, use one of the following methods.

Method 1

To work around this issue for Visual C++ applications, for Visual Basic 6 applications, and for Microsoft .NET applications, follow these steps.

Notes
  • Method 2 does not apply VBA to applications. The compiled Access file (*.mde or *.accde) has to read the downloaded typelib (.tlb) file at runtime, and it is unlikely that the downloaded .tlb file will be present on end-user computers.
  • To download files, go to the "Downloads" subsection of this section.
  • Running the CMD prompt as an Administrator during the registration process for the type library may be necessary on the Windows 7 machines.

For 32-bit computers

  1. Download Msado60_Backcompat_i386.tlb to a local directory (e.g. C:\temp).
  2. Copy the downloaded file to a deployed directory. For example:
    C:\temp\Msado60_Backcompat_i386.tlb "%CommonProgramFiles%\System\ado\Msado60_Backcompat.tlb"
  3. Register the downloaded file on the system. For example:
    %windir%\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "%CommonProgramFiles%\System\ado\msado60_Backcompat.tlb"

    Note Adjust the path for regtlbv12.exe if the .NET Framework 4.0 was not installed on the system.
  4. Verify that the following registry key was created:
    HKEY_CLASSES_ROOT\TypeLib\{0C0FF45D-87C8-4333-9075-3D9B4D64F9FC}\6.0
  5. Verify that the following registry value is pointing to "%CommonProgramFiles%\System\ado\Msado60_Backcompat.tlb" (the path in the registry may be expanded into an absolute path):
    HKEY_CLASSES_ROOT\TypeLib\{0C0FF45D-87C8-4333-9075-3D9B4D64F9FC}\6.0\0\win32

For AMD 64 computers

  1. Download Msado60_Backcompat_i386.tlb to a local directory (e.g. C:\temp).
  2. Download Msado60_Backcompat_x64.tlb to a local directory (e.g. C:\temp).
  3. Copy the downloaded files to a deployed directory. For example:

    C:\Temp\Msado60_Backcompat_i386.tlb "%CommonProgramFiles(x86)%\System\ado\Msado60_Backcompat.tlb"
    C:\Temp\Msado60_Backcompat_x64.tlb "%CommonProgramFiles%\System\ado\msado60_Backcompat.tlb"
  4. Register the downloaded files on the system. For example:

    %windir%\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "%CommonProgramFiles%\System\ado\Msado60_Backcompat.tlb"
    %windir%\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "%CommonProgramFiles(x86)%\System\ado\Msado60_Backcompat.tlb"

    Note Adjust the path for regtlbv12.exe if the .NET Framework 4.0 was not installed on the system.
  5. Verify that the following registry key was created:
    HKEY_CLASSES_ROOT\TypeLib\{0C0FF45D-87C8-4333-9075-3D9B4D64F9FC}\6.0
  6. Verify that the following registry value is pointing to "%CommonProgramFiles(x86)%\System\ado\msado60_Backcompat.tlb" (the path in the registry may be expanded into an absolute path):
    HKEY_CLASSES_ROOT\TypeLib\{0C0FF45D-87C8-4333-9075-3D9B4D64F9FC}\6.0\0\win32
  7. Verify that the following registry value is pointing to "%CommonProgramFiles%\System\ado\msado60_Backcompat.tlb" (the path in the registry may be expanded into an absolute path):
    HKEY_CLASSES_ROOT\TypeLib\{0C0FF45D-87C8-4333-9075-3D9B4D64F9FC}\6.0\0\win64

For IA64 computers

Use the same procedure as for AMD64 computers, but download Msado60_Backcompat_ia64.tlb instead of Msado60_Backcompat_x64.tlb.

Downloads

  • Msado60_Backcompat_i386.tlb (http://download.microsoft.com/download/6/4/3/64318ED2-7E18-4A5C-80E2-9BDA0DF02DB3/msado60_Backcompat_i386.tlb)
  • Msado60_Backcompat_x64.tlb (http://download.microsoft.com/download/6/4/3/64318ED2-7E18-4A5C-80E2-9BDA0DF02DB3/msado60_Backcompat_x64.tlb)
  • Msado60_Backcompat_ia64.tlb (http://download.microsoft.com/download/6/4/3/64318ED2-7E18-4A5C-80E2-9BDA0DF02DB3/msado60_Backcompat_ia64.tlb)

For C++ developers

  1. Replace line 1 with line 2:
    1. #import "msado15.dll" no_namespace rename("EOF","EndOfFile")
    2. #import "msado60_Backcompat.tlb" no_namespace rename("EOF","EndOfFile")
  2. Recompile the application.

For Visual Basic 6 developers

  1. On the Project menu, click References.
  2. Click to clear the Microsoft ActiveX Data Objects * Library and Microsoft ActiveX Data Objects Recordset * Library entries.
  3. Click to select the Microsoft ActiveX Data Objects 6.0 BackCompat Library entry.
  4. Recompile the application.

Method 2

You can change your application so that it uses late binding. For example, you would call the ADO APIs through the IDispatch interface in C++.

Note This workaround does not apply to Visual Basic for Applications applications.

MORE INFORMATION

The following is a complete list of interfaces that have the old IID together with the suffix "_Deprecated" that is added to the interface name:
  • Interface: ADORecordsetConstruction
  • Interface: ConnectionEventsVt
  • Interface: _Connection
  • Interface: Connection15
  • DispInterface: ConnectionEvents
  • Interface: _Command
  • Interface: Command25
  • Interface: Command15
  • Interface: Fields
  • Interface: Fields20
  • Interface: Fields15
  • Interface: Field
  • Interface: Field15
  • Interface: Field20
  • Interface: _Parameter
  • Interface: Parameters
  • Interface: _Record
  • Interface: _Recordset
  • Interface: Recordset21
  • Interface: Recordset20
  • Interface: Recordset15
  • DispInterface: RecordsetEvents
  • Interface: RecordsetEventsVt
  • Interface: _Stream
A better solution for the Windows 7 SP1 ADO GUID changes
http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx (http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx)

APPLIES TO
  • Windows 7 Enterprise
  • Windows 7 Home Basic
  • Windows 7 Home Premium
  • Windows 7 Professional
  • Windows 7 Starter
  • Windows 7 Ultimate
  • Microsoft Windows XP Service Pack 3
  • Microsoft Windows Server 2003 Service Pack 2
  • Windows Vista Business
  • Windows Vista Business 64-bit Edition
  • Windows Vista Enterprise
  • Windows Vista Enterprise 64-bit Edition
  • Windows Vista Home Basic
  • Windows Vista Home Basic 64-bit Edition
  • Windows Vista Home Premium
  • Windows Vista Home Premium 64-bit Edition
  • Windows Vista Service Pack 1
  • Windows Vista Service Pack 2
  • Windows Vista Starter
  • Windows Vista Ultimate
  • Windows Vista Ultimate 64-bit Edition
  • Windows Server 2008 Datacenter
  • Windows Server 2008 Datacenter without Hyper-V
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Enterprise without Hyper-V
  • Windows Server 2008 for Itanium-Based Systems
  • Windows Server 2008 for Windows Essential Server Solutions
  • Windows Server 2008 for Windows Essential Server Solutions without Hyper-V
  • Windows Server 2008 Foundation
  • Windows Server 2008 Standard
  • Windows Server 2008 Standard without Hyper-V
  • Windows Server 2008 R2 Datacenter
  • Windows Server 2008 R2 Datacenter without Hyper-V
  • Windows Server 2008 R2 Enterprise
  • Windows Server 2008 R2 Enterprise without Hyper-V
  • Windows Server 2008 R2 for Embedded Systems
  • Windows Server 2008 R2 for Itanium-Based Systems
  • Windows Server 2008 R2 Foundation
  • Windows Server 2008 R2 Standard
  • Windows Server 2008 R2 Standard without Hyper-V
Keywords: 
kbprb kbsurveynew kbprogramming kbtshoot KB2517589