February 25, 2021
Hot Topics:

Book Review: Beginning Visual Basic 6 Databases

  • By John Percival
  • Send Email »
  • More Articles »

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 .OpenSchema 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.

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.

What we Learned

  • Programming ADO is very similar to DAO
  • We program to ADO, but it is the OLE DB provider that does the real work of taking the ADO commands and translating them to work with the data source
  • The Connection Wizard can be used to seamlessly create the connection string
  • Once we are connected to an OLE DB data source, we can access data almost exactly like DAO
  • Declaring an object variable implicitly or explicitly requires us to handle the variable differently when bringing it to life
  • Transactions are not only useful when working with several recordsets, but can speed up everyday data access tasks

And now we will move on to another cool use of ADO - building our own bound ADO ActiveX control.

Page 23 of 23

This article was originally published on November 20, 2002

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date