7.1. Ambiguous References

In versions prior to Access 2000, the DAO object library was selected by default when a new database was created, allowing developers to write code using DAO.

Access 2000 selected the ADO object library by default (supposedly expecting developers to write using ADO), but this move generated much heartache, because Microsoft didn't adequately advise anyone of the change. Since average Access developers didn't know the difference between the two object models, the first they learned about it was when their applications started generating errors in code that had previously worked.

By the time Microsoft realized the ramifications, Access 2002 was already in beta, and the ADO preselection remained, but the issue is resolved in Access 2003. In Access 2003, both object libraries are preselected.

That being the case, writing unambiguous code has never been more important, because, for the first time, the very real possibility exists that a novice developer could inadvertently write ambiguous code. So what does this all mean? Consider the following:

Dim db As Database
Dim rs As Recordset

Nothing terribly strange there, except for two things: First, only DAO has a Database object—ADO has none. Second, DAO and ADO both have Recordset objects. If both DAO and ADO object libraries are selected, to which object model does the above recordset declaration refer?

If you have only one library referenced, Access chooses that one, but if you have two, Access encounters the ambiguity and lets you know about it in what can seem to be very strange ways.

We have seen code written by professional Access developers, in which both DAO and ADO objects had been used interchangeably, and they could not understand why their code failed to work.

Therefore, to ensure that Access (and you) know which object refers to which object library, you need to disambiguate your code. The following example demonstrates this principle:

Dim db As DAO.Database
Dim cn As ADODB.Connection
Dim rsDAO As DAO.Recordset
Dim rsADO As ADODB.Recordset

Doing this can also make your code run a tad faster, because Access doesn't have to examine the library list to figure out which library to use.