Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

msado15.dll trouble

34 views
Skip to first unread message

BobLarsonFanClub4Jesus

unread,
Aug 4, 2010, 1:21:34 AM8/4/10
to
I've got some custom software I wrote in C++ that uses msado15.dll
2.81.1117.0.

This is all good. In addition, I have several workstation/servers I
plan to run this app on. Actually they're running an earlier version
(2.71) file. Problem is this version causes my custom software to
have a connection to database failure.

Loading the most recent MDAC would solve this problem. But if I do
that, it'll screw up other software on these servers. I don't want
this. They currently run some software that communicates with SQL 9,
and then simulates back to a remote server. After having upgraded the
SQL driver, things get incredibly slow and
nonfunctional.

I'd really prefer to leave these MDAC's non-updated. I originally had
the idea to just copy in the latest version of msado15.dll. But as
I've learned in the newsgroups I apparently can't do that. And it
appears that I won't even be able to unregister it in it's native
location, create a directory, register it there and be done. It won't
even allow me to delete it since it comes right back due to the new
security.

I'm considering just replacing the file in the DLLCACHE directory as a
work around, but that just might open up more issues as hinted by
reading some Microsoft articles.

If you have a solution to this, I'm ready as this has put a standstill
to my software for which I've been writing for a very long time.

ralph

unread,
Aug 4, 2010, 3:48:05 AM8/4/10
to

[Warning! A likely unsatisfactory answer/response follows. <g>]

MsAdo15.dll does not exists in a vacuum as you have found out.
Some background, (hopefully not too pedantic <g>):

The MDACs were labeled as per the highest level of ADO they supported.
However, they are all back-ward compatible. For example, the last MDAC
version released was for ADO 2.8 and thus was labeled MDAC 2.8 but
contain support for ADO 2.5 - 2.8.
The MDACs not only included the ado library (msado15.dll) but also
updated providers and OLE compents (OLE DB). These suites are
platform-specific, thus you have to have a matched suite of components
- that is why you will always run into trouble if you try and just pop
in your own component.

[http://msdn.microsoft.com/en-us/library/ms810805.aspx]

Therefore you should be developing against a particular ADO version
(2.5-2.8) and should NOT be concerned with any particular version of
the msado.dll. Only with whether that version of *ADO* is supported by
the MDAC/DAC components on the target machine.

Now with that said. It looks like you are limited to supporting ADO
2.7. But ADO 2.7 was a tad of a quicky 'fill-in'. Unless you have a
reason to use some the new features of 2.7 - then you might consider
just using ADO 2.5. ADO 2.5 is very stable. But that is just IMHO.

Also it doesn't matter if your development box is MDAC 2.71, MDAC 2.8,
or DAC 6. If you compile with an ADO version the target can support
then all will be well.

hth
-ralph

0 new messages