When You Should Use Macros and When You Shouldn't

In Access 2003, there's just one task that you can perform only by using macros: reassigning key combinations (using the AutoKeys macro). This hour gives you many other examples of macros, but that's just so you can have a basic understanding of macros and how they work. If you are developing a large-scale corporate application, you might consider limiting your use of macros to AutoKeys macros. As you will see later in this section, VBA code is much more appropriate for most of the tasks a large-scale corporate application must perform.

A second common use of macros is as a starting point for an application. Although macros aren't the only choice for this in Access 2003, the AutoExec macro is one of two choices for this task. For more information about the AutoExec macro, see the section "Creating an AutoExec Macro," later in this hour.

However, macros aren't the best tool for creating code that controls industrial-strength applications because they're quite limited in both function and capability. Access macros are limited in the following ways:

• You can't include error handling in an Access macro.

• You can't create user-defined functions by using macros.

• Access macros don't allow you to create variables or pass parameters.

• Access macros provide no method of processing table records one at a time.

• When you use Access macros, you can't use object linking and embedding (OLE) automation or dynamic data exchange (DDE) to communicate with other applications.

• It's more difficult to debug Access macros than it is to debug VBA code.

• You can't perform transaction processing when using Access macros.

• You can't call Windows application programming interface (API) functions by using Access macros.

• You can't perform any replication by using Access macros.

• Access macros don't allow you to create database objects at runtime.