Two functionally equivalent pieces of code, but one has an advantage: -
CODE
Option Explicit
Option Compare Text
Public Sub Case1()
Dim rst As DAO.Recordset
Dim dbs As DAO.Database
Set dbs = CurrentDb()
Set rst = dbs.OpenRecordset("tblMyTable", dbOpenDynaset)
Do Until rst.EOF
MsgBox rst!SomeText
rst.MoveNext
Loop
rst.Close
Set rst = Nothing
dbs.Close
Set dbs = Nothing
End Sub
Public Sub Case2()
With CurrentDb.OpenRecordset("tblMyTable", 2)
Do Until .EOF
MsgBox .Fields("SomeText")
.MoveNext
Loop
.Close
End With
End Sub
Option Compare Text
Public Sub Case1()
Dim rst As DAO.Recordset
Dim dbs As DAO.Database
Set dbs = CurrentDb()
Set rst = dbs.OpenRecordset("tblMyTable", dbOpenDynaset)
Do Until rst.EOF
MsgBox rst!SomeText
rst.MoveNext
Loop
rst.Close
Set rst = Nothing
dbs.Close
Set dbs = Nothing
End Sub
Public Sub Case2()
With CurrentDb.OpenRecordset("tblMyTable", 2)
Do Until .EOF
MsgBox .Fields("SomeText")
.MoveNext
Loop
.Close
End With
End Sub
In case1 everything has been declared as DAO (something or other).
This incurs two penalties.
The first is obvious and minor, the code is longer.
The second is that it requires a reference to DAO.
In case2 the code is shorter and requires no reference to DAO.
It does not matter if references are or are not declared for DAO or ADO or at which priority they might occur.
It simply doesn't matter.
Please also note that DAO constants, such as dbOpenDynaset, should not be used but rather their numerical equivalent substituted.
What this boils down to is that, by writing more code to disambiguate the difference between DAO and ADO, our code has become dependent on references.
If we can avoid the disambiguation we also avoid reference problems and if we avoid reference problems our code becomes more portable.
Regards,
Chris.