Microsoft Access 2010 Bible

Chapter 15: Using Access Data Macros

575

FIGURE 15.19

Saving a macro as XML

Recognizing the Limitations

of Data Macros

As powerful as they are, data macros can’t do everything. For example, data macros have no user

interface at all. Data macros can’t display a message box and can’t open a form or report. Your abil-

ity to communicate with the user interface from a data macro is very limited, so data macros can’t

be used to notify users of problems or changes to data in tables. Displaying a user interface (such

as a message box) would extract a serious performance penalty, particularly during bulk updates or

inserts. Data macros are meant to run invisibly, with the highest possible performance.

Data macros are attached directly to Access tables and not to individual fields. If you have a situa-

tion where more than a few fields must be monitored or updated, the macro may become quite

complex. Using the If block construct is a good way to conditionally execute blocks of macro

statements.

The Macro Designer supports only one macro at a time. You must come to a stopping point on the

current macro before closing it and opening another data macro.

Similarly, the Macro Designer is modal. You can’t leave the Macro Editor without closing and sav-

ing (or not saving) the current macro. This restriction makes it difficult to view a table’s data when

working on a data macro’s logic. As always, careful planning is a good idea when considering add-

ing a data macro to a table.

Data macro execution doesn’t occur on the back end in a split-database paradigm. Although the

data macro resides in the table in the back-end database, the data macro is only executed in the

front end.

Data macros can’t work on multi-value or attachment fields. If it’s important to use logic to control

these data types, you must use traditional user-interface macros or VBA.