Access 2010: The Missing Manual

Data Macros

So far, you’ve seen how to make a macro run when a specific event occurs in a form. However, you can also make a macro run when an event occurs in a table. This feature, which is new in Access 2010, gives you a way to make smarter tables that log changes, synchronize values, and refuse to accept bad data.

Macros that respond to table events are called data macros, and they follow different rules than the macros you’ve seen so far. Although you create data macros using the same macro designer, you’ll notice that data macros support a different set of actions. For example, data macros can’t do anything user-interface related (like show a message box or open a form), and they can’t perform risky actions (like running an application, deleting a database object, or starting a printout). In fact, pretty much the only things data macros can do are create a record, edit a record, and send an email. There’s good reason for this design—it means data macros are light, efficient, and fast.

Data macros are analogous to a concept called triggers that’s featured in server-based databases like SQL Server. There’s a reason for that, too. Microsoft’s ultimate goal is to make data macros portable—in other words, to make sure that data macros can stick with your database even if you transfer it to another platform. For example, your data macros keep right on working if you convert your database to a web database (Chapter 23). Technically, it’s possible for data macros to survive the journey ...