Chapter 12: The Access Event Model
459
The BeforeInsert and AfterInsert events are related to transferring a new record from the
form to an underlying data source. BeforeInsert fires as Access is about to transfer the data,
and AfterInsert is triggered after the record is committed to the data source. For example, you
could use these events to perform a logging operation that keeps track of additions to a table.The BeforeUpdate and AfterUpdate events are frequently used to validate data before it’s
sent to the underlying data source. As you’ll see later in this chapter, many form controls also sup-
port BeforeUpdate and AfterUpdate. A control’s update is triggered as soon as the data in
the control is changed.Tip
A form’s Update event fires much later than the BeforeInsert or AfterInsert events. The Update
event occurs just as the form prepares to move to another record. Many developers use the form’s
BeforeUpdate event to scan all the controls on the form to ensure that all the data in the form’s controls is
valid. A form’s BeforeUpdate event includes a Cancel parameter that, when set to True, causes the
BeforeUpdate event to terminate. Canceling an update event is an effective way to protect the integrity of
the data behind an Access application.
Tip
Users often want to be notified of pending updates before they move off a record to another record. By
default, Access forms automatically update a form’s underlying data source as the user moves to another
record or closes the form. The Dirty event fires whenever the user changes any of the data on a form. You
can use the Dirty event to set a module-level Boolean (true/false) variable (let’s call it boolDirty) so that
other controls on the form (such as a close button) know that pending changes exist on the form. If bool-
Dirty is True when the close button is clicked or when the BeforeUpdate event fires, you can display an
Are you sure? message box to confirm the user’s intention to commit the changes to the database.
Control event procedures
Controls also raise events. Control events are often used to manipulate the control’s appearance or
to validate data as the user makes changes to the control’s contents. Control events also influence
how the mouse and keyboard behave while the user works with the control. A control’s
BeforeUpdate event fires as soon as focus leaves the control (more precisely, BeforeUpdate
fires just before data is transferred from the control to the recordset underlying the form, enabling
you to cancel the event if data validation fails), whereas a form’s BeforeUpdate does not fire
until you move the form to another record. (The form’s BeforeUpdate commits the entire
record to the form’s data source.)This means that a control’s BeforeUpdate is good for validating a single control while the form’s
BeforeUpdate is good for validating multiple controls on the form. The form’s BeforeUpdate
would be a good place to validate that values in two different controls are in agreement with each
other (such as a zip code in one text box, and the city in another text box), instead of relying on
the BeforeUpdate in each of the controls.You create event procedures for control events in exactly the same way you create procedures for
form events. You select [Event Procedure] in the Property Sheet for the event, and then add