Yesterday, I was talking about the BeforeUpdate form event and BeforeUpdate Access control event as ways I was looking at triggering a validation function and then canceling the event so the update would not occur.

A reader wrote in to mention usage of the Change event for an unbound textbox.

I think I mentioned it in passing yesterday, but it is important (and often not simple) to understand how Access fires events in different scenarios.

Here is an article from Microsoft showing some info about the order of events and it’s a good primer, but the ins and outs of when events fire, what state the control is in at that time, and what you can actually do during that event (like saving the record which is sometimes an illegal action during a BeforeUpdate form event for example) are just a few of the questions that often come up.

In my article yesterday, if my form was not bound to a table, query, or recordset, the “BeforeUpdate” event would never actually fire for example. And controls that are not bound as well as different types of controls have different behaviors during the Change event.

The way I’ve dealt with these issues is to do manual testing on the particular form and control I’m using to figure out how it is working and then adjust my code accordingly. As I write this, I’m thinking it would be good to add some functions to my company Access library to manage some of these oddities that I experience on a regular basis and maybe pass controls to the functions to normalize some of the functionality for myself. Hmmm… food for thought.