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

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.

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.

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.

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.

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.

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.

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.

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