Click here to Skip to main content
Click here to Skip to main content
Technical Blog

Your ADO is broken

, 17 Jul 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
Microsoft has violated the holy rules of COM and broken their msado15.dll. The violation occurs after the installation of Windows 7 Service Pack 1 (version 6.1.7601.17514).

I found today that Microsoft has violated the holy rules of COM and broken their msado15.dll. The violation occurs after the installation of Windows 7 Service Pack 1 (version 6.1.7601.17514).

What’s happened is Microsoft has changed a few function signatures due to a 64bit problem, and changed the class IDs while they are at it. Thus, backwards compatibility has been broken, making COM absolutely useless. Executables compiling on Windows7 SP1 will now only run on Windows7 SP1. We’ll have to assume that any other alternatives were carefully thought through and resulted in the world ending, because on face value this looks like a terrible fix.

In this epic saga spanning five months, we’ve still not reached a warm fuzzy conclusion. The best solution seems to be reverting this change made in the service pack and created a new set of 64bit functions. This would probably break all ADO code compiled in the last five months, but at least the last 15 years would work again.

In the meantime, here’s our official workarounds:

  1. Use late binding. Because, you know, type safety and efficiency aren’t all that.
  2. Uninstall Service Pack 1. I think they are laughing at us.
  3. Temporary workaround for C++ developers. Yay!

So we’ll go for the only attractive option, #3. Details are here: http://support.microsoft.com/kb/2517589, but it basically boils down to installing and registering a file called “Msado60_Backcompat”, which is a truly ironic name if you remember what the whole point of COM is.

Except I’d deviate a little from the recommended steps, because forcing your team to install and register these files is a bit inefficient, and playing around in your common files location is plain nasty. There’s also no indication on how to swap them in and out for 32 and 64 bit builds. So here’s my lazy “it-just-works” method for Visual Studio 2010:

  1. In your 3rd party area of your source control, create a branch for Microsoft and Ado. Then branch off for the 64bit and 32bit versions, i.e.
    3rd Party
    =>Microsoft
    ====>Ado
    ======>x86
    ======>x64 
  2. Download the 64 and 32 bit .tlb files, place them in their respective folders and rename them both to “msado60_Backcompat.tlb”.
  3. Check these files in.
  4. Open up properties for your project, and under C/C++, add the path to your tlb files.

    Shows the proprties screen in Visual Studio 2010. The path to the new ADO .tlb file has been added to the additional Directories field,

    Add the path to the .tlb file to Additional Directories

    Don’t forget Release settings!

  5. Do the same for your 64 bit version.
  6. Change the #import "msado15.dll" part in your code to #import "msado60_Backcompat.tlb"
  7. Recompile, build, wait for the next hotfix to come along and destroy your working programs.

Meanwhile, your programs will just work using COM black magic that nobody really understands.

I can only assume everyone who understands COM at Microsoft who could have prevented this fairly fundamental error from occurring has gone mad, senile or died. I know they are keen to get us all writing .NET code (I hear that’s what the cool kids are doing these days), but if no-one understands the technology that .NET is built on, we’re in trouble. I imagine in the near future, mythical COM developers will be held up in great esteem like a lost Mayan civilisation, revered as demi-gods with alien intelligence and magical powers. Or starving as unemployable geeks crying into their RSI-riddled hands.

Share

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

WebBiscuit
Software Developer Web Biscuit
United Kingdom United Kingdom
At Web Biscuit, you can find software, articles, a good dollop of quality and an unhealthy obsession over biscuits.
Website: http://www.webbiscuit.co.uk
Twitter Watch: http://twitter.com/WebBiscuitCoUk

Comments and Discussions

 
QuestionDelphi 7 ADO error PinmemberMember 443749316-Jun-14 1:53 
QuestionI have same problem Pinmemberaliosa_sbbv15-Mar-12 5:26 
QuestionMy Vote of 5 and MS is working on it PinmemberJochen Arndt20-Jan-12 3:12 
GeneralMy vote of 5 PinmemberShameel9-Aug-11 23:07 
QuestionAnother problem in 64... maybe related? Pinmemberronhash6-Aug-11 22:34 
QuestionThanks PinmemberFunkySteve4-Aug-11 18:12 
GeneralThanks, we have the same problem too. Pinmembercoronys18-Jul-11 19:20 
GeneralMy vote of 5 Pinmemberjstoutjr18-Jul-11 10:23 
SuggestionAnother workaround (C++) PinmemberM.Oerder15-Jul-11 2:09 
We have had the exact same problem.
Before Win7SP1 our implementation looked like this:
 
#import "msadox.dll" rename_namespace("ADOXCG") rename("EOF","EndOfFile")
using namespace ADOXCG;
#import "msado15.dll" rename_namespace("ADOCG") rename("EOF","EndOfFile")
using namespace ADOCG;
#import "msjro.dll" no_namespace
 
Our workaround:
 
#import "msadox.dll" rename_namespace("ADOXCG") rename("EOF","EndOfFile")
using namespace ADOXCG;
#import "msado15.dll" rename_namespace("ADOCG") rename("EOF","EndOfFile") \
	exclude("_Connection", "_Command", "_Parameter", "_Recordset") \
	rename("_Connection_Deprecated", "_Connection") \
	rename("_Command_Deprecated", "_Command") \
	rename("_Parameter_Deprecated", "_Parameter") \
	rename("_Recordset_Deprecated", "_Recordset")
using namespace ADOCG;
#import "msjro.dll" no_namespace
 
Fortunately the old functions are still present in the library files but they have be renamed.
By renaming them again during import the old implementation of the modified functions will be called again.
Depending on the functions used this has to be extended/modified.
There is no need to exchange or copy any files.
 
I am not sure if all problems can be solved that way, but our software works like before SP1.
The workaround can only be used when compiling on Win7 machines that have SP1 installed.
GeneralRe: Another workaround (C++) PinmemberHoitabuam6-Nov-12 3:56 
GeneralMy vote of 5 PinmemberSnorri15-Jul-11 0:53 
Questionno rule broken PinmemberSteveKing14-Jul-11 21:10 
AnswerRe: no rule broken PinmemberSnorri15-Jul-11 0:52 
AnswerRe: no rule broken PinmemberWebBiscuit15-Jul-11 6:29 
GeneralRe: no rule broken PinmemberSnorri9-Aug-11 5:32 
Questionlook good! Pinmember ThatsAlok 13-Jul-11 20:13 
AnswerRe: look good! PinmemberWebBiscuit14-Jul-11 7:47 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Mobile
Web01 | 2.8.141022.2 | Last Updated 17 Jul 2011
Article Copyright 2011 by WebBiscuit
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid