We covered a lot of ground in this chapter. We noted how ADO really evolved from DAO's inability to retrieve non-relational data. We saw how the need to access non-relational data was largely driven by the rise of the Internet, and by the problems of accessing the wealth of legacy data stored in a variety of formats.
We noted how the move to ADO was really evolutionary, not revolutionary. ODBC was a first attempt to permit a single interface to work with many database providers products. But ODBC, while still powerful, was limited to relational data. ADO breaks these bounds and allows us to access everything we could get hold of with ODBC, plus much more.
The basic way to retrieve an ADO recordset is by first opening a connection to the database. We examined the ins and outs of a connection string and even built our own Data Source Name (DSN), and we opened an ADO connection using that.
Next we used ADO to examine the data provider's tables and fields by using the
method. This permitted us to see exactly how the data source was made up. We then went on to look at the Errors collection and how it is used in the ADO object model..OpenSchema
Moving on to cursors, we caught a glimpse of what really happens under the hood when data is returned to us in a recordset. An example was shown opening a recordset with a specific cursor.
We then ended up with transactions and discussed how they can not only help when we need to update several tables simultaneously, but can also really speed up our code when we have more 'garden variety' tasks such as updating several records.