Opening and closing Database Objects
- Open the Clients table. You can use one of these two methods: Double-click the object you want to open, in this case the clients table, or Select the object you want to open (we have already highlighted the clients table for you) and click Open on the Database window toolbar.
- Click the Table window maximize button to see more of the table.
- Close the Clients table. You can use the Clients table close button, which appears directly beneath the Access window close button, to close the table.
- View the list of forms in the database. Use the Object bar to view the different types of objects in the database--click Forms to see the forms in the database.
- Open the Clients form. You can use one of these two methods: Double-click the object you want to open--in this case the Clients form, or select the object you want to open (since the Clients form is the only object available it will automatically be highlighted)
and click Open on the Database window toolbar.
- Click the Clients form window close button to close the Clients form and return to the Database window.
- You have now successfully opened and closed table and form objects within the Database window.
Working with Data
The first thing to note when discussing data access objects is that the DAO and ADO object models
are separate from the Access object model. DAO and ADO represent the objects managed and
"owned" by the Access database engines (ACE or Jet), which are software components installed along with Office. In the past, Excel (with the MSQuery add-on) and Visual Basic (the stand-alone application development product) could directly use the Jet database engine or access it through
open database connectivity (ODBC) or Microsoft Query.
Using Access VBA enables you to manipulate your database objects behind the scenes, giving you a great amount of flexibility within your applications. Access provides two different
object models for working with data: ADO and DAO.
ADO is the newer of the two syntaxes. It’s based on Microsoft’s ActiveX technology, which provides the basis for independent objects that perform complex tasks without input from their hosts. When applied to ADO, the ActiveX objects are able to perform a wide variety of data access tasks without hampering Access in any way. Because ADO objects are quite powerful, the ADO object model (meaning, the ADO object hierarchy) is fairly sparse. Only
a few objects are needed to perform virtually all data access tasks in Access applications.
Prior to ADO, the data access object model supported by Access was DAO. Unlike ADO, DAO
objects are simple and direct, and they are part of a more complex hierarchy of objects. In
recent versions, Microsoft has revived DAO by building it into the Access Database Engine.
The distinction between Access and DAO is important because Access’s user interface tends
to blur the line between objects belonging to Access and those belonging to the database
engine. There are some features available in code that you may think are data access objects
but are really features of Access, and vice versa. In code, you’ll have to develop with this
distinction in mind. For example, ADO and DAO objects have many built-in properties and
methods; other properties are added by Access.