An ADO application that is re-compiled on a Windows 7 Service Pack 1-based computer does not run on down-level operating systems

View products that this article applies to.

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

Expand all | Collapse all

SYMPTOMS

Consider the following scenario. On a Windows 7 Service Pack 1-based computer, you re-compile a Microsoft ActiveX Data Objects (ADO) application by using one of the following applications:

Microsoft Visual C++
Microsoft Visual Basic for Applications
Microsoft Visual Basic 6

In this scenario, you find that the application does not run on down-level operating systems, such as the release version of Windows 7, Windows Vista, and other earlier versions of Windows. Depending on your implementation, you 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

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:

Support Statement for Visual Basic 6.0 on Windows Vista, Windows Server 2008 and Windows 7 (http://msdn.microsoft.com/en-us/vbasic/ms788708.aspx)

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

Back to the top

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.

Back to the top

WORKAROUND

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

Method 1: You can install the following hotfix on the client computer. This hotfix adds new IIDs to the system. For more information about this workaround, see the followning Knowledge Base article:
983246 (http://support.microsoft.com/kb/983246/ ) "Type Mismatch" error message when you run a VBA macro in a 64-bit version of an Office 2010 application
Method 2: To work around this issue for a Visual C++ application, follow these steps:
1. Build the project. This creates the msado15.tlh and msado15.tli files in the Debug/Release folder on the release version of Windows 7 or on earlier versions of Windows.
2. Copy the msado15.tlh and msado15.tli files into the source directory for your project.
3. Edit the code, and delete the following string:
  #import "msado15.tlb" no_namespace rename("EOF","EndOfFile")
4. Type the following to replace the deleted string:
  #include "msado15.tlh"
5. Rebuild the project.
Note The msado15.tli file location in the msado15.tlh file is as follows:
C:\MyProject\release\msado15.tli
You may have to change the path of the msado15.tli file manually in the msado15.tlh file. This removes any dependency on the build operating system from your project.
Method 3: In a Visual C++ application, you can change all your interface references by adding the "_Deprecated" suffix. These old IIDs will be supported in future releases of Windows.
Method 4: You can change your application so that it uses late binding. For example, you would call the ADO APIs through the IDispatch interface in Visual C++.

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