I have a VBA program written in Excel 97 on one machine
(machine A) with a reference pointing to ADO Ext. 2.5 for
Security and DDL. The VBA program was modified on another
machine (machine B) also running Excel 97 but with a
reference to ADO Ext. 2.6...instead.

After the modifications on machine B, the reference is no
longer ADO Ext. 2.5 and changed to pointing to ADO Ext.
2.6 now.

When re-running it on machine A, the program gave many
errors and the reference was showing "Missing ADO Ext. 2.6
for Security and DDL".

My question was how to change the settings on either of
the machines to make the program work again on machine A.
Is there anyway to downgrade to ADO Ext. 2.5 for Security
and DDL to make it run well on machine A?

Thanks a lot!

"Derek Richards" wrote in
:

I have a VBA program written in Excel 97 on one machine
(machine A) with a reference pointing to ADO Ext. 2.5 for
Security and DDL. The VBA program was modified on another
machine (machine B) also running Excel 97 but with a
reference to ADO Ext. 2.6...instead.

After the modifications on machine B, the reference is no
longer ADO Ext. 2.5 and changed to pointing to ADO Ext.
2.6 now.

When re-running it on machine A, the program gave many
errors and the reference was showing "Missing ADO Ext. 2.6
for Security and DDL".

My question was how to change the settings on either of
the machines to make the program work again on machine A.
Is there anyway to downgrade to ADO Ext. 2.5 for Security
and DDL to make it run well on machine A?

Thanks a lot!



I ran into a similar problem when developing on a Windows XP machine for
deployment on Windows 2000 machines. XP has the ADO ext 2.7 installed as
part of the core system which created problems since the other machines
only had 2.5 installed.

The only resolution I found was to use late-binding for the ADO
Extensibility objects. Even though it isn't the best solution, it might
be the only one if you can't get everyone running the same version of ADO.

HTH!

--
Andrew Mauer
----------------
To reply directly, remove .nospam from email

I disagree. I think late binding *is* the best solution.

--

Andrew Mauer wrote in message . 248.16...
"Derek Richards" wrote in
:

I have a VBA program written in Excel 97 on one machine
(machine A) with a reference pointing to ADO Ext. 2.5 for
Security and DDL. The VBA program was modified on another
machine (machine B) also running Excel 97 but with a
reference to ADO Ext. 2.6...instead.

After the modifications on machine B, the reference is no
longer ADO Ext. 2.5 and changed to pointing to ADO Ext.
2.6 now.

When re-running it on machine A, the program gave many
errors and the reference was showing "Missing ADO Ext. 2.6
for Security and DDL".

My question was how to change the settings on either of
the machines to make the program work again on machine A.
Is there anyway to downgrade to ADO Ext. 2.5 for Security
and DDL to make it run well on machine A?

Thanks a lot!



I ran into a similar problem when developing on a Windows XP machine for
deployment on Windows 2000 machines. XP has the ADO ext 2.7 installed as
part of the core system which created problems since the other machines
only had 2.5 installed.

The only resolution I found was to use late-binding for the ADO
Extensibility objects. Even though it isn't the best solution, it might
be the only one if you can't get everyone running the same version of ADO.

HTH!

Thanks for all of you. How to use the late binding in
detailed steps?


-----Original Message-----
I disagree. I think late binding *is* the best solution.

--

Andrew Mauer wrote in
message
. 248.16..
..
"Derek Richards"
wrote in
:

I have a VBA program written in Excel 97 on one
machine
(machine A) with a reference pointing to ADO Ext. 2.5
for
Security and DDL. The VBA program was modified on
another
machine (machine B) also running Excel 97 but with a
reference to ADO Ext. 2.6...instead.

After the modifications on machine B, the reference
is no
longer ADO Ext. 2.5 and changed to pointing to ADO
Ext.
2.6 now.

When re-running it on machine A, the program gave
many
errors and the reference was showing "Missing ADO
Ext. 2.6
for Security and DDL".

My question was how to change the settings on either
of
the machines to make the program work again on
machine A.
Is there anyway to downgrade to ADO Ext. 2.5 for
Security
and DDL to make it run well on machine A?

Thanks a lot!



I ran into a similar problem when developing on a
Windows XP machine for
deployment on Windows 2000 machines. XP has the ADO
ext 2.7 installed as
part of the core system which created problems since
the other machines
only had 2.5 installed.

The only resolution I found was to use late-binding for
the ADO
Extensibility objects. Even though it isn't the best
solution, it might
be the only one if you can't get everyone running the
same version of ADO.

HTH!
.

In a nutshell, to change from early to late bound:

• replace variables dim'ed with class name with Object type;
• replace instantiation (New keyword) with CreateObject;
• replace enumerations with constants.

Here's some example code. The two procedures are the same but for binding:

Sub TestEarlyBound()

Dim oConn As ADODB.Connection
Dim oRs As ADODB.Recordset
Dim strSql As String

Set oConn = New ADODB.Connection

With oConn
.CursorLocation = adUseClient
.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & strPATH
.Open
End With

strSql = "SELECT RefID, Surname" & _
" FROM PersonalDetails"

Set oRs = oConn.Execute(strSql)

' <code

oRs.Close
oConn.Close

End Sub

Sub TestLateBound()

Dim oConn As Object
Dim oRs As Object
Dim strSql As String

Set oConn = CreateObject("ADODB.Connection")

With oConn
.CursorLocation = 3 ' adUseClient
.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=" & strPATH
.Open
End With

strSql = "SELECT RefID, Surname" & _
" FROM PersonalDetails"

Set oRs = oConn.Execute(strSql)

' <code

oRs.Close
oConn.Close

End Sub

--

"Derek" wrote in message ...
Thanks for all of you. How to use the late binding in
detailed steps?


-----Original Message-----
I disagree. I think late binding *is* the best solution.

--