Other variable qualifiers

You can qualify a 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 variable definition.

Table 4. Variable qualifiers
Keyword	Followed by
INITIAL	The variable's initial value.
DECIMALS	The number of decimal places for a DECIMAL variable.
FORMAT	The display format of the variable, enclosed in quotation marks.
LABEL	The label to display with the variable. (The default is the variable name itself.)
COLUMN-LABEL	The label to display with the variable when it is displayed as part of a column of values. (The default is the LABEL if there is one, otherwise the variable name.)
EXTENT	An integer constant. This qualifier allows you to define a variable that is a one-based array of values. You can then reference the individual array elements in your code by enclosing the array subscript in square brackets, as in myVar[2] = 5.

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've previously defined:

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's one more keyword that you should almost always use at the end of your variable definitions, 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 don't 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.