Unexpected error 132's - Forum - OpenEdge General - Progress Community
 Forum

Unexpected error 132's

This question is answered

I am having some trouble trying to determine where all of the errors are coming from that I am seeing.

If I run the below code...

DEFINE TEMP-TABLE ttList NO-UNDO
    FIELD tId   AS INTEGER
INDEX tabix IS PRIMARY UNIQUE tId.

MAINBLOCK:
DO ON ERROR UNDO, LEAVE:

    CREATE ttList.
    ASSIGN ttList.tId = 1.

    CREATE ttList.
    ASSIGN ttList.tId = 1.

END. /* MAINBLOCK */

I see ** ttList already exists with  1. (132), but I see it 4 times.

So if I change the code to add some messages, like the below...

DEFINE TEMP-TABLE ttList NO-UNDO
    FIELD tId   AS INTEGER
INDEX tabix IS PRIMARY UNIQUE tId.

MAINBLOCK:
DO ON ERROR UNDO, LEAVE:

    MESSAGE "1" VIEW-AS ALERT-BOX INFO BUTTONS OK.

    CREATE ttList.
    ASSIGN ttList.tId = 1.

    MESSAGE "2" VIEW-AS ALERT-BOX INFO BUTTONS OK.

    CREATE ttList.
    ASSIGN ttList.tId = 1.

END. /* MAINBLOCK */

MESSAGE "3" VIEW-AS ALERT-BOX INFO BUTTONS OK.

I then see message 1 and 2, then I see the first error 132 (as expected), then I see message 3, but then I see the other 3 error 132's before I return back to the editor.

I don't understand why I am getting the additional error 132 messages?

OpenEdge 10.2B08
Windows 7 (64 bit)

Verified Answer
  • The short version why the error repeats:

    - Because the temp-table is no-undo the 2nd record stays in the buffer. (if the temp-table is undoable AND a transaction is active the buffer will be emptied while the record is undone).

    - The AVM tries to flush buffers that moved out of scope at certain points. (Such as when a procedure ends.) And it validates the current contents when doing so to prevent the underlying table from going into an inconsistent state. Every time such a flush happens, the error will be raised again and the buffer sticks around because it can't be flushed correctly.

    Two ways to avoid this:

    1. Make the temp-table undoable and wrap any activity on it in a transaction. Which is probably not the most efficient way, and may introduce transaction scoping issues as a side effect.

    2. In the block where you create temp-table records, CATCH any error that occurs. Then in the CATCH block delete the record and re-throw the exception. (Re-throwing is under the assumption that you *do* want the initial error to remain visible to the rest of your code )

All Replies
  • The short version why the error repeats:

    - Because the temp-table is no-undo the 2nd record stays in the buffer. (if the temp-table is undoable AND a transaction is active the buffer will be emptied while the record is undone).

    - The AVM tries to flush buffers that moved out of scope at certain points. (Such as when a procedure ends.) And it validates the current contents when doing so to prevent the underlying table from going into an inconsistent state. Every time such a flush happens, the error will be raised again and the buffer sticks around because it can't be flushed correctly.

    Two ways to avoid this:

    1. Make the temp-table undoable and wrap any activity on it in a transaction. Which is probably not the most efficient way, and may introduce transaction scoping issues as a side effect.

    2. In the block where you create temp-table records, CATCH any error that occurs. Then in the CATCH block delete the record and re-throw the exception. (Re-throwing is under the assumption that you *do* want the initial error to remain visible to the rest of your code )

  • Much appreciated Frank, a very thorough explanation.