Microsoft ADO Ext. 2.5 vs. 2.6 for DDL...

[Derek Richards]

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!

 

[Andrew Mauer]

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!

 

[onedaywhen]

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

--

 

[Derek]

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

 

[onedaywhen]

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

--