Distributing MDBs that reference ADO

[GPO]

Hi,

I'm just after confirmation that I'm on the right track.
Our organisation has just distributed to about 50 other
organisations, an MDB that references ADO 2.8.

A few have had problems running it and upon investigation,
when viewing Tools> References in VBE, references to ADO
and ADOX are prefixed with "Missing"

I have found three links that might solve this problem
(apologies for the wrapping):

(1)
http://support.microsoft.com/default.aspx?
scid=http://support.microsoft.com:80/support/kb/articles/Q1
95/0/49.ASP&NoWebContent=1

(2)
http://groups.google.com/groups?hl=en&lr=&ie=UTF-
8&threadm=u9wJt%24AVBHA.2264%
40tkmsftngp05&rnum=4&prev=/groups%3Fhl%3Den%26lr%3D%26ie%
3DUTF-8%26q%3Ddistributing%2BADO%26btnG%3DSearch%26meta%
3Dgroup%253Dmicrosoft.public.access.*

(3)
http://support.microsoft.com/default.aspx?
scid=http://support.microsoft.com:80/support/kb/articles/Q1
95/0/49.ASP&NoWebContent=1

Am I on the right track here? Are there any other ADO
distribution traps of which I need to be aware?

 

[Douglas J. Steele]

Not sure what your "track" is, since you don't say what you're intending to
do! (BTW, your 3rd reference is the same as the 1st one: I assume you meant
to refer to http://support.microsoft.com/?id=201580 )

If you're distributing to organizations outside of your own (so that you
have no control as to what they do or don't have on their desktops), I'm not
sure any of the approaches outlined will be 100% reliable as each of them
seems to imply that you can land on a specific version of ADO being present
and run with it. For example, 201580 has you point to the TLB file for a
specific version of ADO rather than simply using MSADO15.DLL (which is the
file installed by all versions of ADO), and while 195049 allows you to
reference MSADO15.DLL, it still requires you to pick a particular version of
ADO (although it should work if you pick a sufficiently old version)

Unfortunately, Access tends to be a little less forgiving about reference
versioning than other applications, so I'm not 100% certain the approach
outlined in 195049 will necessarily work: Access may refuse to acknowledge
MSADO15.DLL if you pointed to a different version of it than is present on
your users' machines.

You may have to settle for putting in logic to determine whether they've got
the referenced file in the correct location (and it's the same version) and
stop them from proceeding unless they install the appropriate version of
MDAC.

 

[GPO]

Sorry Doug,

(I think you've answered my question to an extent anyway!)

The mdb that we've distributed references ADO 2.8.
Evereyone who has had problems, has had a version between
ADO 2.1 and 2.7. Is there a technique we can use that
finds earlier versions of ADO transparently to the end
user? The issue is that the end users often get very poor
IT support, and some are just as likely not to bother with
product if it means having to download and install the
latest MDAC. Their desktops may be locked down and
requests to their IT (particularly a software upgrade like
MDAC) can take months once all of the layers of bureacracy
have been transcended. In short, the easier we make life
for them the better.

The ADO functionality we use seems to be pretty standard
stuff so, assuming it is compatible with 2.1, could we
just reference 2.1 in tools>references or would it be
safer to use the ADODB.[_Recordset21] nomenclature?

Incidentally we distributed the same thing last year using
DAO. Seven times faster, no library/reference problems,
richly featured, loved by one and all... This year though,
the edict came down from on high that DAO had to go,
because it was too "Access specific". So we've "upgraded"
to the slower and bulkier ADO, and it doen't run unless
the user happens to be running from the same MDAC as us.
Fun, fun, fun!

Cheers!

GPO

 

[Douglas J. Steele]

I'm really not that up on inter-version issues with ADO, I'm afraid, but my
assumption would be that if you reference 2.1 in your application, it will
fail for anyone who does have msado21.tlb on their machine. I've never used
the ADODB.[_Recordset21] approach (I'm fortunate to be in a environment
where standardization is taken very seriously), but if it works for you, it
might be a sounder approach.

Alternatives would be to put code in to check whether the user has
msado21.tlb in the expected location, and stop the application if they
don't, or using Late Binding:

Dim rsCurr As Object

Set rsCurr = CreateObject("ADODB.Recordset")

instead of

Dim rsCurr As ADODB.Recordset

Set rsCurr = New ADODB.Recordset

(Note that when you use Late Binding, you lose all named constants
associated with ADO, so you have to define them to your program)

--
Doug Steele, Microsoft Access MVP

(No private e-mails, please)

Sorry Doug,

(I think you've answered my question to an extent anyway!)

The mdb that we've distributed references ADO 2.8.
Evereyone who has had problems, has had a version between
ADO 2.1 and 2.7. Is there a technique we can use that
finds earlier versions of ADO transparently to the end
user? The issue is that the end users often get very poor
IT support, and some are just as likely not to bother with
product if it means having to download and install the
latest MDAC. Their desktops may be locked down and
requests to their IT (particularly a software upgrade like
MDAC) can take months once all of the layers of bureacracy
have been transcended. In short, the easier we make life
for them the better.

The ADO functionality we use seems to be pretty standard
stuff so, assuming it is compatible with 2.1, could we
just reference 2.1 in tools>references or would it be
safer to use the ADODB.[_Recordset21] nomenclature?

Incidentally we distributed the same thing last year using
DAO. Seven times faster, no library/reference problems,
richly featured, loved by one and all... This year though,
the edict came down from on high that DAO had to go,
because it was too "Access specific". So we've "upgraded"
to the slower and bulkier ADO, and it doen't run unless
the user happens to be running from the same MDAC as us.
Fun, fun, fun!

Cheers!

GPO

-----Original Message-----
Not sure what your "track" is, since you don't say what you're intending to
do! (BTW, your 3rd reference is the same as the 1st one: I assume you meant
to refer to http://support.microsoft.com/?id=201580 )

If you're distributing to organizations outside of your own (so that you
have no control as to what they do or don't have on their desktops), I'm not
sure any of the approaches outlined will be 100% reliable as each of them
seems to imply that you can land on a specific version of ADO being present
and run with it. For example, 201580 has you point to the TLB file for a
specific version of ADO rather than simply using MSADO15.DLL (which is the
file installed by all versions of ADO), and while 195049 allows you to
reference MSADO15.DLL, it still requires you to pick a particular version of
ADO (although it should work if you pick a sufficiently old version)

Unfortunately, Access tends to be a little less forgiving about reference
versioning than other applications, so I'm not 100% certain the approach
outlined in 195049 will necessarily work: Access may refuse to acknowledge
MSADO15.DLL if you pointed to a different version of it than is present on
your users' machines.

You may have to settle for putting in logic to determine whether they've got
the referenced file in the correct location (and it's the same version) and
stop them from proceeding unless they install the appropriate version of
MDAC.

--
Doug Steele, Microsoft Access MVP

(No private e-mails, please)





.

 

[GPO]

I've used late binding for the Excel automation in the program and it wasn't
as daunting as I thought it might be, so I might try it with the ADO stuff
too.

Many thanks.

I'm really not that up on inter-version issues with ADO, I'm afraid, but my
assumption would be that if you reference 2.1 in your application, it will
fail for anyone who does have msado21.tlb on their machine. I've never used
the ADODB.[_Recordset21] approach (I'm fortunate to be in a environment
where standardization is taken very seriously), but if it works for you, it
might be a sounder approach.

Alternatives would be to put code in to check whether the user has
msado21.tlb in the expected location, and stop the application if they
don't, or using Late Binding:

Dim rsCurr As Object

Set rsCurr = CreateObject("ADODB.Recordset")

instead of

Dim rsCurr As ADODB.Recordset

Set rsCurr = New ADODB.Recordset

(Note that when you use Late Binding, you lose all named constants
associated with ADO, so you have to define them to your program)

--
Doug Steele, Microsoft Access MVP

(No private e-mails, please)

Sorry Doug,

(I think you've answered my question to an extent anyway!)

The mdb that we've distributed references ADO 2.8.
Evereyone who has had problems, has had a version between
ADO 2.1 and 2.7. Is there a technique we can use that
finds earlier versions of ADO transparently to the end
user? The issue is that the end users often get very poor
IT support, and some are just as likely not to bother with
product if it means having to download and install the
latest MDAC. Their desktops may be locked down and
requests to their IT (particularly a software upgrade like
MDAC) can take months once all of the layers of bureacracy
have been transcended. In short, the easier we make life
for them the better.

The ADO functionality we use seems to be pretty standard
stuff so, assuming it is compatible with 2.1, could we
just reference 2.1 in tools>references or would it be
safer to use the ADODB.[_Recordset21] nomenclature?

Incidentally we distributed the same thing last year using
DAO. Seven times faster, no library/reference problems,
richly featured, loved by one and all... This year though,
the edict came down from on high that DAO had to go,
because it was too "Access specific". So we've "upgraded"
to the slower and bulkier ADO, and it doen't run unless
the user happens to be running from the same MDAC as us.
Fun, fun, fun!

Cheers!

GPO

-----Original Message-----
Not sure what your "track" is, since you don't say what you're intending to
do! (BTW, your 3rd reference is the same as the 1st one: I assume you meant
to refer to http://support.microsoft.com/?id=201580 )

If you're distributing to organizations outside of your own (so that you
have no control as to what they do or don't have on their desktops), I'm not
sure any of the approaches outlined will be 100% reliable as each of them
seems to imply that you can land on a specific version of ADO being present
and run with it. For example, 201580 has you point to the TLB file for a
specific version of ADO rather than simply using MSADO15.DLL (which is the
file installed by all versions of ADO), and while 195049 allows you to
reference MSADO15.DLL, it still requires you to pick a particular version of
ADO (although it should work if you pick a sufficiently old version)

Unfortunately, Access tends to be a little less forgiving about reference
versioning than other applications, so I'm not 100% certain the approach
outlined in 195049 will necessarily work: Access may refuse to acknowledge
MSADO15.DLL if you pointed to a different version of it than is present on
your users' machines.

You may have to settle for putting in logic to determine whether they've got
the referenced file in the correct location (and it's the same version) and
stop them from proceeding unless they install the appropriate version of
MDAC.

--
Doug Steele, Microsoft Access MVP

(No private e-mails, please)


Hi,

I'm just after confirmation that I'm on the right track.
Our organisation has just distributed to about 50 other
organisations, an MDB that references ADO 2.8.

A few have had problems running it and upon investigation,
when viewing Tools> References in VBE, references to ADO
and ADOX are prefixed with "Missing"

I have found three links that might solve this problem
(apologies for the wrapping):

(1)
http://support.microsoft.com/default.aspx?
scid=http://support.microsoft.com:80/support/kb/articles/Q1
scid=http://support.microsoft.com:80/support/kb/articles/Q1
95/0/49.ASP&NoWebContent=1

Am I on the right track here? Are there any other ADO
distribution traps of which I need to be aware?


.