This is a
much more direct route and provides better performance. ADO also gives us many settings to
help fine-tune how we interact with our data. We can choose to run our cursor on the server
(in a connected environment) or on the client (if the database supports it, in a disconnected
environment).
I mentioned my use of explicit reference to DAO and ADO in my variable declarations
earlier. This is due to the fact that Microsoft made ADO the default data mechanism with the
release of Access 2000. Up until that time, Dim rs As Recordset meant a DAO recordset object
to Access and nothing else. After the release of Access 2000, that same line of code referred to
an ADO recordset. Having started out in life as an Access developer, I relied heavily on DAO in
many of my applications. After upgrading to Access 2000 and beginning to use ADO (along
with DAO), I learned to make my declarations complete to avoid confusing the compiler (not
to mention debugging!).
In any application that uses both access protocols, explicitly creating your objects eliminates
any confusion. Your application will always know the difference between an object
declared as DAO.Recordset and one declared as ADODB.Recordset. If you do not explicitly
declare your DAO or ADO objects, whichever object is higher in the references list will get
priority. If the ADO 2.8 library is listed above the DAO 3.6 library, then any object declared as
type Recordset will default to the ADO library.
ADO Example 1: Importing SQL Data
For our first ADO example, we??™re going to use the AdventureWorks sample database provided
by Microsoft.
Pages:
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93