From: Tony Toews on
Folks

I'm wanting to determine the version of various DAO, MSJet, ACE and
ADO DLLs.

One means of doing this is by using a CSIDL to get to C:\Program
Files\Common Files\system\ado\msado15.dll (or close and then adding
on system\ado as requiired.)

Elsewhere it has been suggested that I should use the CLSID. In this
case the entire key is
HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32
which I got from http://support.microsoft.com/kb/266668

Is this a relable method especially if dealing with other language
OSs? Is this the best, recommended method?

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
From: Mayayana on
It's reliable on Win32 if the object is registered.
If you can use CreateObject, that listing has to
be there. That's how COM makes it possible to find
the object. But if the object is out-of-process the
key is LocalServer32 rather than InProcServer32.
Application objects and ActiveX EXEs are in that
category.

Watch out for 2 things when parsing the path string,
though. There could be switches in the path. (Check
for " /" and snip it off if found.) The path string
may also need to be expanded. (Check for "%" in
the string.)

I don't know how it works with a 64-bit library,
but that shouldn't matter if you're running 32-bit.


| I'm wanting to determine the version of various DAO, MSJet, ACE and
| ADO DLLs.
|
| One means of doing this is by using a CSIDL to get to C:\Program
| Files\Common Files\system\ado\msado15.dll (or close and then adding
| on system\ado as requiired.)
|
| Elsewhere it has been suggested that I should use the CLSID. In this
| case the entire key is
|
HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32
| which I got from http://support.microsoft.com/kb/266668
|
| Is this a relable method especially if dealing with other language
| OSs? Is this the best, recommended method?
|
| Tony
| --
| Tony Toews, Microsoft Access MVP
| Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
| Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
| For a convenient utility to keep your users FEs and other files
| updated see http://www.autofeupdater.com/


From: Tony Toews on
On Wed, 7 Jul 2010 23:19:05 -0400, "Mayayana"
<mayayana(a)invalid.nospam> wrote:

> It's reliable on Win32 if the object is registered.
>If you can use CreateObject, that listing has to
>be there.

Ah, excellent. That can work although usually a reference is used for
ADO/DAO within Access.

>That's how COM makes it possible to find
>the object. But if the object is out-of-process the
>key is LocalServer32 rather than InProcServer32.
>Application objects and ActiveX EXEs are in that
>category.

Ok, now I'm not understanding all this but then prat of that is I do
not fully understand what COM means.

> Watch out for 2 things when parsing the path string,
>though. There could be switches in the path. (Check
>for " /" and snip it off if found.) The path string
>may also need to be expanded. (Check for "%" in
>the string.)

Switch I can handle. % maybe not.

> I don't know how it works with a 64-bit library,
>but that shouldn't matter if you're running 32-bit.

No, that part I don't care about yet although I might given that
Access 2010 comes in a 64 bit edition.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
From: Kevin Provance on
Have you ever thought about attempting to create the ADO object through
code? If it succeeds, it's installed. If it errors out, trap the error and
throw it away, not installed.

--
Customer Hatred Knows No Bounds at MSFT
Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc

Bawwk! Paulie want a dingleball, bawwk!
"Tony Toews" <ttoews(a)telusplanet.net> wrote in message
news:esea3611q3nq5re7nnc77u7f1lk6c5bksd(a)4ax.com...
: Folks
:
: I'm wanting to determine the version of various DAO, MSJet, ACE and
: ADO DLLs.
:
: One means of doing this is by using a CSIDL to get to C:\Program
: Files\Common Files\system\ado\msado15.dll (or close and then adding
: on system\ado as requiired.)
:
: Elsewhere it has been suggested that I should use the CLSID. In this
: case the entire key is
:
HKEY_CLASSES_ROOT\CLSID\{00000535-0000-0010-8000-00AA006D2EA4}\InprocServer32
: which I got from http://support.microsoft.com/kb/266668
:
: Is this a relable method especially if dealing with other language
: OSs? Is this the best, recommended method?
:
: Tony
: --
: Tony Toews, Microsoft Access MVP
: Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
: Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
: For a convenient utility to keep your users FEs and other files
: updated see http://www.autofeupdater.com/

From: Nobody on
"Tony Toews" <ttoews(a)telusplanet.net> wrote in message
news:esea3611q3nq5re7nnc77u7f1lk6c5bksd(a)4ax.com...
> Folks
>
> I'm wanting to determine the version of various DAO, MSJet, ACE and
> ADO DLLs.

For ADO, you can check Version property of the Connection object.