List of ADO GUID strings
 

Could somebody tell me the list of all the Microsoft ActiveX Data Objects 2
GUID's and Major's and Minor's?
I am trying to write a foolproof procedure to add the most up-to-date ADO
reference.

I got these sofar, but how about 2.5, 2.4, 2.3, and 2.2?

ADODB Microsoft ActiveX Data Objects 2.0 Library C:\Program Files\Common
Files\system\ado\msado20.tlb
{00000200-0000-0010-8000-00AA006D2EA4} 2 0

ADODB Microsoft ActiveX Data Objects 2.1 Library C:\Program Files\Common
Files\system\ado\msado21.tlb
{00000201-0000-0010-8000-00AA006D2EA4} 2 1

ADODB Microsoft ActiveX Data Objects 2.6 Library C:\Program Files\Common
Files\system\ado\msado26.tlb
{00000206-0000-0010-8000-00AA006D2EA4} 2 6

ADODB Microsoft ActiveX Data Objects 2.7 Library C:\Program Files\Common
Files\system\ado\msado27.tlb
{EF53050B-882E-4776-B643-EDA472E8E3F2} 2 7

ADODB Microsoft ActiveX Data Objects 2.8 Library C:\Program Files\Common
Files\system\ado\msado15.dll
{2A75196C-D9EB-4129-B803-931327F72D5C} 2 8

Looked everywhere, but can't find this.


RBS

List of ADO GUID strings
 

I don't think I understand why you want to use the GUID, the least intuitive
bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last installed
version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8 and if you
ran the same code on a PC with 2.6 only, you will reference 2.6.

If you hardcode the GUID, all PCs will have to have the same version as on
the development PC for your code to work.

List of ADO GUID strings
 

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I can use
2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target machine
has a higher version
then that higher version won't be automatically used as the lower versions
can still be present.
Maybe there is no harm to use say 2.1 if the user has 2.8, but I might as
well go for the higher
version and I think my method will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive
bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last installed
version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8 and if
you
ran the same code on a PC with 2.6 only, you will reference 2.6.

If you hardcode the GUID, all PCs will have to have the same version as on
the development PC for your code to work.

List of ADO GUID strings
 

I just wrote this this. Works on my machine but no guarantees
for misc client setups..

Approach:
find the inprocserver for the current version of a com object in the
registry. Use that file to create the reference in VB.

Sub Demo()
ThisWorkbook.VBProject.References.AddFromFile _
GetLibrary("adodb.connection")
End Sub

Function GetLibrary(sProgID$) As String
Dim oReg As Object, sDat$
Const HKCR = &H80000000
Set oReg = GetObject( _
"winmgmts:{impersonationLevel=impersonate}!\\.\roo t\default:StdRegProv")
oReg.getstringvalue _
HKCR, sProgID & "\CLSID", vbNullString, sDat
oReg.getstringvalue _
HKCR, "CLSID\" & sDat & "\Inprocserver32", vbNullString, sDat
GetLibrary = sDat
End Function

--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I can use
2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target
machine has a higher version then that higher version won't be
automatically used as the lower versions can still be present. Maybe
there is no harm to use say 2.1 if the user has 2.8, but I might as
well go for the higher version and I think my method will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last
installed version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8
and if you ran the same code on a PC with 2.6 only, you will
reference 2.6.

If you hardcode the GUID, all PCs will have to have the same
version as on the development PC for your code to work.

List of ADO GUID strings
 

Hi KeepITCool,

Thanks for that and I will give that a go.
Not that it may be necessary, but would it set a reference to say 2.8 if the
registry key:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
says 2.7?

Do you see any pitfalls with my suggested approach?
I want to avoid late binding and I don't think I have to.

RBS


"keepITcool" wrote in message
.com...

I just wrote this this. Works on my machine but no guarantees
for misc client setups..

Approach:
find the inprocserver for the current version of a com object in the
registry. Use that file to create the reference in VB.

Sub Demo()
ThisWorkbook.VBProject.References.AddFromFile _
GetLibrary("adodb.connection")
End Sub

Function GetLibrary(sProgID$) As String
Dim oReg As Object, sDat$
Const HKCR = &H80000000
Set oReg = GetObject( _
"winmgmts:{impersonationLevel=impersonate}!\\.\roo t\default:StdRegProv")
oReg.getstringvalue _
HKCR, sProgID & "\CLSID", vbNullString, sDat
oReg.getstringvalue _
HKCR, "CLSID\" & sDat & "\Inprocserver32", vbNullString, sDat
GetLibrary = sDat
End Function

--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I can use
2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target
machine has a higher version then that higher version won't be
automatically used as the lower versions can still be present. Maybe
there is no harm to use say 2.1 if the user has 2.8, but I might as
well go for the higher version and I think my method will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last
installed version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8
and if you ran the same code on a PC with 2.6 only, you will
reference 2.6.

If you hardcode the GUID, all PCs will have to have the same
version as on the development PC for your code to work.

List of ADO GUID strings
 

Have tested on my machine and it does indeed add the 2.8 reference
even though that reg key says version is 2.71
Will have to study it a bit as I don't understand it yet, but it looks neat.
Thanks again.

RBS

"keepITcool" wrote in message
.com...

I just wrote this this. Works on my machine but no guarantees
for misc client setups..

Approach:
find the inprocserver for the current version of a com object in the
registry. Use that file to create the reference in VB.

Sub Demo()
ThisWorkbook.VBProject.References.AddFromFile _
GetLibrary("adodb.connection")
End Sub

Function GetLibrary(sProgID$) As String
Dim oReg As Object, sDat$
Const HKCR = &H80000000
Set oReg = GetObject( _
"winmgmts:{impersonationLevel=impersonate}!\\.\roo t\default:StdRegProv")
oReg.getstringvalue _
HKCR, sProgID & "\CLSID", vbNullString, sDat
oReg.getstringvalue _
HKCR, "CLSID\" & sDat & "\Inprocserver32", vbNullString, sDat
GetLibrary = sDat
End Function

--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I can use
2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target
machine has a higher version then that higher version won't be
automatically used as the lower versions can still be present. Maybe
there is no harm to use say 2.1 if the user has 2.8, but I might as
well go for the higher version and I think my method will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last
installed version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8
and if you ran the same code on a PC with 2.6 only, you will
reference 2.6.

If you hardcode the GUID, all PCs will have to have the same
version as on the development PC for your code to work.

List of ADO GUID strings
 

With latebinding the most recent typelibrary is used.
My function will simply find the library file of the current version.

I cant see your scenario happening. (if 2.8 is installed it must be the
"current version"


Study the registry:
MDAC.Version will refer to current (most recent) version.

HKCR\
MDAC.Version
MDAC.Version.2.71
MDAC.Version.2.80
all have same CLSID:{54AF9350-1923-11D3-9CA4-00C04F72C514}

Then in:
CLSID\{54AF9350-1923-11D3-9CA4-00C04F72C514}
the PROGID points BACK to MDAC.Version.2.80


--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Hi KeepITCool,

Thanks for that and I will give that a go.
Not that it may be necessary, but would it set a reference to say 2.8
if the registry key:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
says 2.7?

Do you see any pitfalls with my suggested approach?
I want to avoid late binding and I don't think I have to.

RBS


"keepITcool" wrote in message
.com...

I just wrote this this. Works on my machine but no guarantees
for misc client setups..

Approach:
find the inprocserver for the current version of a com object in the
registry. Use that file to create the reference in VB.

Sub Demo()
ThisWorkbook.VBProject.References.AddFromFile _
GetLibrary("adodb.connection")
End Sub

Function GetLibrary(sProgID$) As String
Dim oReg As Object, sDat$
Const HKCR = &H80000000
Set oReg = GetObject( _
"winmgmts:{impersonationLevel=impersonate}!\\.\roo t\default:StdRegPr
ov") oReg.getstringvalue _
HKCR, sProgID & "\CLSID", vbNullString, sDat
oReg.getstringvalue _
HKCR, "CLSID\" & sDat & "\Inprocserver32", vbNullString, sDat
GetLibrary = sDat
End Function

-- keepITcool
www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I
can use 2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target
machine has a higher version then that higher version won't be
automatically used as the lower versions can still be present.
Maybe there is no harm to use say 2.1 if the user has 2.8, but I
might as well go for the higher version and I think my method
will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last
installed version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8
and if you ran the same code on a PC with 2.6 only, you will
reference 2.6.

If you hardcode the GUID, all PCs will have to have the same
version as on the development PC for your code to work.

List of ADO GUID strings
 

OK, so what you are saying is that simply reading:

HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\

won't tell you the current version by itself?

RBS

"keepITcool" wrote in message
.com...

With latebinding the most recent typelibrary is used.
My function will simply find the library file of the current version.

I cant see your scenario happening. (if 2.8 is installed it must be the
"current version"


Study the registry:
MDAC.Version will refer to current (most recent) version.

HKCR\
MDAC.Version
MDAC.Version.2.71
MDAC.Version.2.80
all have same CLSID:{54AF9350-1923-11D3-9CA4-00C04F72C514}

Then in:
CLSID\{54AF9350-1923-11D3-9CA4-00C04F72C514}
the PROGID points BACK to MDAC.Version.2.80


--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Hi KeepITCool,

Thanks for that and I will give that a go.
Not that it may be necessary, but would it set a reference to say 2.8
if the registry key:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
says 2.7?

Do you see any pitfalls with my suggested approach?
I want to avoid late binding and I don't think I have to.

RBS


"keepITcool" wrote in message
.com...

I just wrote this this. Works on my machine but no guarantees
for misc client setups..

Approach:
find the inprocserver for the current version of a com object in the
registry. Use that file to create the reference in VB.

Sub Demo()
ThisWorkbook.VBProject.References.AddFromFile _
GetLibrary("adodb.connection")
End Sub

Function GetLibrary(sProgID$) As String
Dim oReg As Object, sDat$
Const HKCR = &H80000000
Set oReg = GetObject( _
"winmgmts:{impersonationLevel=impersonate}!\\.\roo t\default:StdRegPr
ov") oReg.getstringvalue _
HKCR, sProgID & "\CLSID", vbNullString, sDat
oReg.getstringvalue _
HKCR, "CLSID\" & sDat & "\Inprocserver32", vbNullString, sDat
GetLibrary = sDat
End Function

-- keepITcool
www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I
can use 2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target
machine has a higher version then that higher version won't be
automatically used as the lower versions can still be present.
Maybe there is no harm to use say 2.1 if the user has 2.8, but I
might as well go for the higher version and I think my method
will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last
installed version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8
and if you ran the same code on a PC with 2.6 only, you will
reference 2.6.

If you hardcode the GUID, all PCs will have to have the same
version as on the development PC for your code to work.

List of ADO GUID strings
 

One other question.
Do you think I can be 100% sure that VBS is always present or should
I read the registry with the API to be on the safe side?

RBS

"keepITcool" wrote in message
.com...

I just wrote this this. Works on my machine but no guarantees
for misc client setups..

Approach:
find the inprocserver for the current version of a com object in the
registry. Use that file to create the reference in VB.

Sub Demo()
ThisWorkbook.VBProject.References.AddFromFile _
GetLibrary("adodb.connection")
End Sub

Function GetLibrary(sProgID$) As String
Dim oReg As Object, sDat$
Const HKCR = &H80000000
Set oReg = GetObject( _
"winmgmts:{impersonationLevel=impersonate}!\\.\roo t\default:StdRegProv")
oReg.getstringvalue _
HKCR, sProgID & "\CLSID", vbNullString, sDat
oReg.getstringvalue _
HKCR, "CLSID\" & sDat & "\Inprocserver32", vbNullString, sDat
GetLibrary = sDat
End Function

--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

Yes, late binding is an option, but it has drawbacks as well.

My idea to tackle this is as follows:
Save the wb (an .xla file) with a reference to a low version, 2.1
In the Workbook_Open event remove this reference and loop through
the possible versions down from 2.8 to 2.0 and try adding them.
If successful then exit this loop.
This works fine, but I just need to know a few more versions.

I could read the version from the registry:
HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\
but I have noticed that on my machine this gives me 2.7, but I can use
2.8, so running the loop might be better.

The trouble with ADO is that if I save with say 2.1 and the target
machine has a higher version then that higher version won't be
automatically used as the lower versions can still be present. Maybe
there is no harm to use say 2.1 if the user has 2.8, but I might as
well go for the higher version and I think my method will work.

RBS


"AA2e72E" wrote in message
...
I don't think I understand why you want to use the GUID, the least
intuitive bit of information about objects.

The latest version of ADO is 2.8.

If you use late binding, you automatically pick up the last
installed version, e.g.

Set ADOC = CreateObject("ADODB.Connection")
Set ADORS = CreateObject("ADODB.Recordset")

So, if you ran the code on a PC with 2.8, you will reference 2.8
and if you ran the same code on a PC with 2.6 only, you will
reference 2.6.

If you hardcode the GUID, all PCs will have to have the same
version as on the development PC for your code to work.

List of ADO GUID strings
 

The function uses WMI not VBS
But yes: to be safe use API for registry stuff.

--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

One other question.
Do you think I can be 100% sure that VBS is always present or should
I read the registry with the API to be on the safe side?

RBS

List of ADO GUID strings
 

not sure. Many things i dont understand about all this ClsID
registration etc.

You need the type library for the com object adodb.connection
my function does exactly that (no more no less).

Note:
add error handlers:

in case ADODB is not installed or entry corrupted
(very unlikely, but known to happen with registry problems/partial
unnstalls etc )

in case the CLSID points to a file which doesn't exist.
in case the reference already exists.


--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

OK, so what you are saying is that simply reading:

HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\

won't tell you the current version by itself?

RBS

List of ADO GUID strings
 

OK, I have re-written now with API calls and will use that.
It just looks a lot neater than working with an array of GUID's etc.

RBS

"keepITcool" wrote in message
.com...

The function uses WMI not VBS
But yes: to be safe use API for registry stuff.

--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

One other question.
Do you think I can be 100% sure that VBS is always present or should
I read the registry with the API to be on the safe side?

RBS

List of ADO GUID strings
 

Have done the error handlers.
In case of ADO I will remove first the version that is possibly not
the lowst version than add the latest version.
Come to think of it I could first check if the installed one is the latest
one
and if so leave it at that.

RBS

"keepITcool" wrote in message
.com...

not sure. Many things i dont understand about all this ClsID
registration etc.

You need the type library for the com object adodb.connection
my function does exactly that (no more no less).

Note:
add error handlers:

in case ADODB is not installed or entry corrupted
(very unlikely, but known to happen with registry problems/partial
unnstalls etc )

in case the CLSID points to a file which doesn't exist.
in case the reference already exists.


--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

OK, so what you are saying is that simply reading:

HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\

won't tell you the current version by itself?

RBS

List of ADO GUID strings
 

meant: possibly not the highest version.

RBS

"RB Smissaert" wrote in message
...
Have done the error handlers.
In case of ADO I will remove first the version that is possibly not
the lowst version than add the latest version.
Come to think of it I could first check if the installed one is the latest
one
and if so leave it at that.

RBS

"keepITcool" wrote in message
.com...

not sure. Many things i dont understand about all this ClsID
registration etc.

You need the type library for the com object adodb.connection
my function does exactly that (no more no less).

Note:
add error handlers:

in case ADODB is not installed or entry corrupted
(very unlikely, but known to happen with registry problems/partial
unnstalls etc )

in case the CLSID points to a file which doesn't exist.
in case the reference already exists.


--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

OK, so what you are saying is that simply reading:

HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\

won't tell you the current version by itself?

RBS

List of ADO GUID strings
 

Just one more thing with this.
It works fine with ADO, but it is more tricky with DAO for example.
There are 2 keys, eg:
HKEY_CLASSES_ROOT\DAO.DBEngine.35 and
HKEY_CLASSES_ROOT\DAO.DBEngine.36
with different GUID strings.

Will look a bit further.

RBS

"keepITcool" wrote in message
.com...

not sure. Many things i dont understand about all this ClsID
registration etc.

You need the type library for the com object adodb.connection
my function does exactly that (no more no less).

Note:
add error handlers:

in case ADODB is not installed or entry corrupted
(very unlikely, but known to happen with registry problems/partial
unnstalls etc )

in case the CLSID points to a file which doesn't exist.
in case the reference already exists.


--
keepITcool
| www.XLsupport.com | keepITcool chello nl | amsterdam


RB Smissaert wrote in

OK, so what you are saying is that simply reading:

HKEY_CLASSES_ROOT\MDACVer.Version\CurVer\

won't tell you the current version by itself?

RBS