MS-Access / Getting Started

---

Collections, Objects, Properties, and Methods

You have already dealt with two of the main collections supported by Access 2010-Forms and Reports. The Forms collection contains all the form objects that are open in your application, and the Reports collection contains all the open report objects.

As you'll learn in more detail later in this section, collections, objects, properties, and methods are organized in several object model hierarchies. An object has properties, which describe the object, and methods, which are actions that you can ask the object to execute. For example, a Form object has a Name property (the name of the form) and a Requery method (to ask the form to requery its record source). Many objects also have collections that define sets of other objects within the object. For example, a Form object has a Controls collection, which is the set of all control objects (text boxes, labels, and so on) defined on the form.

You don't need a thorough understanding of collections, objects, properties, and methods to perform most application tasks. It's useful, however, for you to know how Access and Visual Basic organize these items so that you can better understand how Access works. If you want to study advanced code examples available in the many sample databases that you can download from public forums, you'll need to understand collections, objects, properties, and methods and how to correctly reference them.

The Access Application Architecture

An Access 2010 desktop application (.accdb or .mdb) has two major components-the application engine, which controls the programming and the user interface, and the Access Database Engine (DBEngine), which controls the storage of data and the definition of all the objects in your database. An Access project (.adp) also uses the application engine, but it depends on its Connection object to define a link to the Microsoft SQL Server database that contains the tables, views, functions, and stored procedures used by the application. As you'll see in the next section, Visual Basic supports two distinct object models (Data Access Objects-DAO, and ActiveX Data Objects-ADO) for manipulating objects stored by the database engine.

When you open a database, the application engine loads the appropriate object collections from the database and application files to enable it to list the names of all the tables, queries, views, database diagrams, stored procedures, forms, reports, macros, and modules to display in the Navigation pane. The application engine establishes the top-level Application object, which contains a Forms collection (all the open forms), a Reports collection (all the open reports), a Modules collection (all the open modules, including form and report modules), and a References collection (all Visual Basic library references). Each form and report, in turn, contains a Controls collection (all of the controls on the form or report). Among some of the more interesting properties of the Application object is the ADOConnectString property that contains the information you can use to connect to this database from another database.

Note: For backward compatibility with earlier versions and database files in the .mdb format, the Access object architecture continues to support obsolete collections, objects, and properties. For example, the Application object continues to support a CommandBars collection to allow you to manipulate any custom menus or toolbars that might have been defined using Access 2003 or earlier.

The Application object also contains two special objects, the Screen object and the DoCmd object. The Screen object has six very useful properties: ActiveForm, ActiveReport, Active- Datasheet, ActiveControl, PreviousControl, and MousePointer. Without knowing the actual names, you can reference the control (if any) that currently has the focus, the datasheet (if any) that has the focus, the form (if any) that has the focus, the report (if any) that has the focus, or the name of the control that previously had the focus. You can use the MousePointer property to examine the current status of the mouse pointer (arrow, I-beam, hourglass, and so on) and set the pointer. (Additional details about referencing properties of objects appear later in this tutorial.) The DoCmd object lets you execute most macro actions within Visual Basic. If your application is an Access desktop database (.accdb), the DBEngine object under the Application object connects you to the Access Database Engine (ACE) to manipulate its objects using the DAO model.

Two properties allow you to directly find out the names of all objects stored in your database without having to call the database engine. In an Access desktop database (.accdb), you can find out the names of all your tables and queries via the CurrentData property. In an Access project file (.adp) that is connected to SQL Server, you also can learn the names of database diagrams, stored procedures, functions, and views via this same property. In either type of Access file, you can discover the names of all your forms, reports, macros, and modules via the CurrentProject property. Finally, the FullName property of the CurrentProject object tells you the full path and file name of your application file, and the Name property tells you the file name only.