Error "Attempt to update data exceeding 32000 . (12371)" raised when assigning a value to a variable

Error "Attempt to update data exceeding 32000 . (12371)" raised when assigning a value to a variable.

May occur when increasing the size of an extent variable (array).

Error is more frequently seen with UNDO variables.

Progress/OpenEdge procedures have two 32KB memory segments to store variables. One is for NO-UNDO variables; the other is for variables that can be undone.  These segments hold all variables of each respective type, including all extents for all arrays. Error (12371) is raised if the total storage required for all variables and/or extents defined in one segment exceeds the 32K segment limit.

For both the "undo" and the NO-UNDO segments,  the following is true:

• The segment is manipulated as a variable length buffer "record".
• Because 32K is the maximum length of a Progress/OpenEdge record, this buffer is also constrained by the 32K limit.
• The buffer holds only variable data, never variable definitions.
• If a variable is defined with the EXTENT keyword (that is, it is an array), Progress reserves 1 byte for each element in the array.
• There is a separate 32K memory buffer for each each external procedure .p file (persistent or not), each internal procedure, and each function or class method. There is also a separate 32K buffer for all GLOBAL variables used in the session; GLOBAL variables are not stored in any procedure's buffers.

However, there are some ways in which NO-UNDO variables work differently than undo-able variables.  For example, the following code will work for NO-UNDO variables, but will fail with error 12371 for undo variables:

DEFINE VARIABLE c1 AS CHARACTER NO-UNDO.
DEFINE VARIABLE c2 AS CHARACTER NO-UNDO.

C1 = FILL("X",30000).
C2 = FILL("X",30000).

The reason for the difference is that Progress attempts an optimization for NO-UNDO variables. When the optimization is possible, a separate 32K buffer is allocated for each NO-UNDO variable.  However, this optimization cannot always be performed.  The decision to optimize or not is made at compile time, based on the following factors:

• All NO-UNDO variables and extents must fit in a single 32K buffer at compile time.
• There cannot be any indeterminate arrays.

If either rule is violated then optimization cannot be performed and all NO-UNDO variables have to fit into one 32K buffer.

Undo-able variables never are allocated separate buffers; they must always fit into a single 32K buffer.

In most cases, 32K is enough space to hold all the variables that must fit in a single undo or NO-UNDO buffer. Error (12371) may be a sign of an application error if the values of all undo or NO-UNDO variables in a procedure or GLOBAL segment are not expected to exceed this limit.

If a procedure defines variables (arrays) with very large extents that may legitimately overrun a 32K buffer, consider one of the following options:

• Define the array as a NO-UNDO variable.
• Define a temp-table rather than an EXTENT (array) to store the data. Temp-tables are stored and handled in a different way and don't take as much memory in the variable storage segments.  While it requires more code to implement a temp-table-based design, the temp-table can contain much more data and is more flexible in usage than an EXTENT variable.

References to Other Documentation:

OpenEdge Getting Started: ABL Essentials, Chapter 7, "Defining and Using Temp-tables"

Progress Articles:
 How to troubleshoot "Attempt to define too many indexes" errors for OpenEdge clients ?