You can qualify a DEFINE VARIABLE definition in a number of ways to modify these defaults. To do this, append one of the keywords listed in the following table to the end of your DEFINE VARIABLE definition.

As an alternative to specifying all of this, you can use the following syntax form to define a variable that is LIKE another variable or database field you previously defined:

DEFINE VARIABLE varname LIKE fieldname.

In this case it inherits the format, label, initial value, and all other attributes of the other variable or field. This is another strength of ABL. Your application procedures can inherit many field attributes from the database schema, so that a change to the schema is propagated to all your procedures automatically when they are recompiled. You can also modify those schema defaults in individual procedures.

There is one more keyword that you should almost always use at the end of your variable defined using DEFINE VARIABLE, and that is NO-UNDO. This keyword has to do with how the AVM manages transactions that update the database. When you define variables in your ABL programs, the AVM places them into two groups:

• Those variables that include the NO-UNDO qualifier are managed by the AVM without transaction support.
• Those variables that do not have the NO-UNDO qualifier are treated as though they were a database record with those variables as fields. If any of the variable values are modified during the course of a database transaction, and then the transaction is backed out, changes to the variable values made during the transaction are backed out as well, so that they revert to their values before the transaction started. This can be very useful sometimes, but in practice, most variables do not need this special treatment, and because the AVM has to do some extra work to manage them, it is more efficient to get into the habit of appending NO-UNDO to the end of your variable definitions unless the variable is one that should be treated as part of a transaction.