Chapter 1

Why Program Access?

As the premiere database management system, Microsoft Access is used by millions all over the
world. If it is so good at storing and retrieving information, why would anyone want to go to the
trouble of programming an application created by Access? Although Access, with all its wizards
and other versatile tools, can produce an amazingly complete and detailed finished application, it
cannot provide all necessary capabilities and services to all users without some help.
By design, Access is meant to provide the most universally useful database features, which it
does with remarkable thoroughness. However, each user or organization is bound to have special
needs and processes that require enhancing the Access database tables, forms, reports, and
queries. As a bonus, programming Access can create a foolproof user interface and significant
error-trapping procedures that can ensure vital database validity. The following are some things
you can do with Access:
Suppose your database is quite large and you need to make the same change to a lot of
records at once. With VBA, you can run through the entire recordset very efficiently in
one operation rather than change the values one-by-one in a form.
If you were operating a mail-order book business and needed to add state tax to the
orders within your own state, you would need to look at the value in the State field of the
customers address. A program can do that for you and add the tax if the customer is in
your home state or omit it, if not.
The validity of your database is very important. You can add procedures that catch
errors in data entry and display meaningful messages to the user. If the error is not
significant, you can display a reminder to return and complete the data entry at a later
date or refuse to move on until the error is corrected.
Suppose you want to extract certain records, such as those for customers from a
particular state, but each time you run the program you might want to see the list of
customers from a different state. Using VBA code, you can prompt the user to enter the
desired value when they run the program.
These are only a few of the cases in which you can benefit by programming Access.
Access As a Front-End Development Tool
Back in the old days, if a noncomputer person wanted a system to manage an important database,
he or she had to hire an expensive programmer/consultant. With the advent of tools such as
Access and Excel, someone with little programming expertise, but a clear picture of the
requirements, can create a sophisticated application in a short amount of time. Access replaces
the high-priced programmer who sat between the end user and the computer.

Chapter 2
Reviewing Access Database Elements
The purpose of this chapter is to review all the elements that make up the Access database
environment. This chapter defines the major objects included in a database and examines the
smaller components that play a part in tables, forms, and reports. In addition, you learn what
makes each element look and behave the way you want.
If you are well acquainted with Access and its elements, you might want to skim over this
chapter and proceed to Chapter 3, Touring the World of Object-Oriented Programming, which
addresses the characteristics of object-oriented programming and how that ties in with your
Access application.
Access Objects and Collections
The catch-all term object refers to an element of an application. In fact, the application itself is
an object that contains all the other objects. In Access, objects form a hierarchy beginning with
the application in a program or library and ending with the detailed controls that make up forms
and reports. Figure 2.1 illustrates the Access object hierarchy.

Figure 2.1. The Access object hierarchy.
Applying property settings and methods to the top-level application object applies them to the
entire application, which sets and retrieves all the options specified in the Options dialog box.
For example, checking the Show Startup Dialog Box property in the View tab of the Options
dialog box (shown in Figure 2.2) applies to the current application. You can also apply methods
and properties to an application to change the default menu bar to a customized one, set the
active object upon startup, and automatically save all files when quitting the application.
Most applications include several forms, reports, and modules. When one or more forms are
open, the group is called a forms collection. For example, you may be looking through a
Products list in a form and at the same time have the Suppliers information form open for
lookup. These two forms belong to the forms collection.

Figure 2.2. You can set application properties and methods in the Options dialog box.
Similarly, the set of open reports or modules are members of the reports or modules collection,
respectively. The objects in these collections are all the same type. That is, they are all forms, all
reports, or all modules.


Tip: Collections come in handy in VBA because you can refer to a member of a collection not only by
name but also by its index within the collection. Forms are indexed based on the order in which they
were opened, beginning with 0. For example, the first form opened is indexed as Forms(0), where Forms
is the name of the collection and (0) indicates that it was the first opened and is still open. The next
forms are indexed as Forms(1), then Forms(2), and so on. If you close the first form, Forms(0), then the
others move up in the index: Forms(1) now becomes Forms(0), and so on. Indexes in a reports collection
behave the same way.



Access Objects
The screen object refers to whatever form, report, or control currently has focus. For example,
while you are modifying a report design, the Report Design window becomes the screen object.
You cannot open a form by referring to the screen object, but you can refer to it to find out which
object is active.
The DoCmd object of an application lets you run most of the Access actions from a VBA
procedure. For example, when you click the Save toolbar button or choose File | Save, Access
carries out the Save action. In a VBA procedure, adding the Save method to the DoCmd object
creates the statement DoCmd.Save, which does the same thing as the Access Save action.
Similarly, the FindNext action that executes when you click the Find Next button in the Find in
Field dialog box can be converted to the VBA statement DoCmd.FindNext. A few of the Access
actions, such as AddMenu and StopMacro, are not covered by DoCmd methods.



Note: The terms action and method can get confusing. An action is a command in a macro or by itself
that responds to a menu selection or button click. A method is a procedure that applies to an object.
The Save action saves a specified Access object or the current one. The Save method carries out the
Save action in VBA and applies to the DoCmd object.



An application has only one screen object and one DoCmd object, so these objects do not form
collections.



Note: Although you see Access tables in the database view, they are not Access objects. They are DAO
(Data Access Object) objects. Earlier versions of Access included Table objects in the DAO, but they
are now referred to as Recordset DAO objects. You learn more about DAO objects in Chapter 3.



Control Objects
At the lowest level, the control objects are contained in and subordinate to form and report
objects. Controls include all the design elements you use to create forms and reports, such as text
boxes, buttons, and labels. A control object can also be contained within or attached to another
control.
Bound controls are linked directly to a field in a table, query, or other element of the database.
Unbound controls are used to display information not related to any database element.
Calculated controls are text boxes that display the results of a calculation. The control source for
a calculated control is a formula or an expression using data from the underlying table or query
or another control. Calculated controls can be bound or unbound.
An example of a calculated control is a text box that contains the total cost of an order by
multiplying the number of items by their unit cost. The calculated control, Extended Cost, would
have the following expression in its control source property box, where Qty and Unit Cost are both
fields in the underlying table or query:
=[Qty]*[Unit Cost]