Access.2007.VBA.Bibl..

I

n older versions of Microsoft Office, there were two choices for working

with data stored in Access tables. One was the Data Access Objects

(DAO) object model, which was developed specifically to work with

Access data in recordsets (including form recordsets) and to work with table

structure using the Tables (and subsidiary Fields) collections. Because of

these customized features, DAO was the best object model for working with

Access data.

The other choice for working with Access data was (and is) the ADO object

model, introduced with Visual Studio 97, and available for use in Office 2000

and up. This object model is intended for working with data in a wide variety

of sources, including Access databases. Although it lacks some of the cus-

tomized features that make DAO so well suited to Access data, ADO code

works fine for basic data manipulation, where you don’t need to work with

Access form recordsets or create tables and fields (in other words, you are just

working with data in Access tables, not with their structure).

Before the release of Office 2007, word was out that Microsoft was dropping

support for the DAO object model (and indeed you can see statements to

this effect in various online Microsoft documents). I wondered whether ADO

would be updated to work with form recordsets, and the Tables (and sub-

sidiary Fields) collection (or some alternate method for creating tables and

their fields programmatically), because there are situations when you need

these features of DAO, while working in an Access database, or creating an

Access add-in.

IN THIS CHAPTER

Using the old and new DAO

object models to work with

Access data

Working with Access databases

in formats from 2000 to 2007

Using the ADO object model to

work with Access data

Converting DAO code to

ADO code

Working with Access Data