Scribd
Upload
131 views2 pages

ADO x32 On x64 Issue

This document discusses an issue where ADO-based applications compiled on Windows 7 SP1 or later do not run on earlier versions of Windows due to changes made to ADO interface identifiers (IIDs) in the later versions. It provides the cause of the issue and resolutions, including recompiling the application on an earlier version of Windows or changing the ADO reference to use backward compatible libraries.

Uploaded by

Bezimeni Usamljeni Vuk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
131 views2 pages

ADO x32 On x64 Issue

This document discusses an issue where ADO-based applications compiled on Windows 7 SP1 or later do not run on earlier versions of Windows due to changes made to ADO interface identifiers (IIDs) in the later versions. It provides the cause of the issue and resolutions, including recompiling the application on an earlier version of Windows or changing the ADO reference to use backward compatible libraries.

Uploaded by

Bezimeni Usamljeni Vuk
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 2

ADO x32on x64 issue

An ADO-based application that is compiled in Windows 7 SP1 or in Windows Server 2008 R2 SP1 does
not run in earlier versions of Windows
https://support.microsoft.com/en-us/kb/2517589
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 Basic 6, Visual Basic for Applications (VBA), Visual C++,.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.
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

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.

https://support.microsoft.com/en-us/kb/2640696

Symptoms
ADO-based applications that are compiled in Windows 7 SP1 or in Windows Server 2008 R2 SP1 use the new interface
identifiers (IIDs) in the ADO type libraries that were included in the SP1 packages for Windows 7
More information
Assume that you compile a VB6-based or VBA-based application that is compatible with versions of Windows that are
earlier than Windows 7 SP1 and Windows Server 2008 R2 SP1. After you install this update, Visual Basic automatically
displays the Microsoft ActiveX Data Objects 6.1 Library in the Available References list when you try to add references to
the current project. To manually locate the ADO 6.0 type library (Msado60.tlb) in this situation, browse to the following
location:

%program files%\common files\system\ado

Visual Basic automatically displays the ADO 6.0 type library in the Available References list if the reference to the ADO 6.0
type library was added to current project.

RESOLUTION
To resolve this issue

1. you recompile a Microsoft ActiveX Data Objects (ADO) application on Windows 7 without Service Pack 1 (SP1) – see
https://blogs.msdn.microsoft.com/psssql/2011/10/02/a-better-solution-for-the-windows-7-sp1-ado-guid-changes/
our standing recommendations were to use either the backward compatible libraries from
http://support.microsoft.com/kb/2517589 or to compile on Windows 7 RTM run time machine: We are going to do
the following: Ship the 6.0 type library from Windows 7 RTM via the new type library file msado60.tlb.  This will
ship for multiple platforms. Ship a new 6.1 type library (which contains both new and deprecated interfaces) and
embed it inside the msado15.dll Revert back all 2.x type libraries to what they looked like in Windows 7 RTM.
Therefore, the 2.x and 6.0 type libraries can be used for backward compatible purposes, and the 6.1 type library
can be used for 64-bit VBA solutions. If you find yourself in the enviable place of not having to do any downlevel OS
support, you can migrate entirely to the 6.1 type library even for your non-VBA applications. Although you can see
this fix in action in the Windows 8

2. Change reference from msado15.dll to msado28.dll for scenario that you recompile your application that must run
in Windows XP, Vista, Server 2008, or in a later version of Windows. Or change to msado60.dll for same as previous
but you are not using MSJRO.

You might also like