If the troubleshooting steps in this article rule out application problems, search the Progress knowledge base for known OpenEdge defects that may cause error (40) and/or (14675), or contact Progress Technical Support for further assistance.
Troubleshooting error (40) / (14675)
Progress 8.x does not provide support for dynamic temp-tables. Statements referring to this feature do not apply this release.
OpenEdge 11.x and later delay the instantiating of static temp-tables until they are actually used. Depending on how the application code is written, this can delay the occurrence of error 14675. Refer to Article:
1. Investigate whether stray dynamic temp-tables and/or persistent procedures are lingering in memory after their due life expectancy.
One way of achieving this is to add code in a location where according to the application logic there should be no or few dynamic temp-tables and persistent procedures, and produce warnings if the number of dynamic temp-tables or persistent procedures increases. Code examples are provided in the following Articles:
2. In OpenEdge 10.x and later, use extended Client Logging
The following is an example of Client Startup parameters to enable - extended logging of transactions, entry into and exit from ABL procedures, and dynamic temp-table, buffer and query objects:
-clientlog <logfilename> -logentrytypes "4GLTrans,4GLTrace,DynObjects.DB:4" -logginglevel 3
This example combines logging for 2 common scenarios:
a.
4GLTrans and
4GLTrace log entry types together at
logginglevel 3 :
Can be used to determine which procedures are being executed within a transaction, to isolate if the problem is caused by making numerous synchronous calls to non-persistent procedures which define static temp-tables during a transaction
b.
DynObjects.DB log entry type at
logginglevel 4 :Logs the creation and deletion of all dynamic temp-tables used. This information can be used to determine if these operations are explicitly coded or implicitly performed by the AVM.
To expand the logging to cover leaking static temp-tables, add the
DynObjects .Class and
DynObjects.Other log entry types. Since static temp-tables are scoped to the
persistent procedures or class that instantiates them, this will identify the programs being leaked.In OpenEdge 11.x, consider using the temp-tables log entry type to expose when the temp-tables are instantiated, deleted or emptied
-clientlog <logfilename> -logentrytypes "Temp-tables" -logginglevel 4
Corrective StepsWhen lingering temp-tables are found, corrective steps depend on the exact nature of the issue.
When dynamic temp-tables created by application code are not cleaned up, add code to do so.
If static temp-tables are defined in non-persistent procedures within a transaction, there are two options (not mutually exclusive):
- Adjust the transaction scope so that it is smaller, or limit the number of iterations per transaction. This allows the temp-tables to be cleaned up before the limit is reached.
- Rework the non-persistent procedure into a persistent one, moving the logic into an internal procedure of the persistent procedure. This allows a single instance of the temp-table to be reused for multiple iterations of the logic.
If static temp-tables are defined in persistent procedures, modify the application code in one of the following ways (not mutually exclusive):
- Ensure that instances of the procedure are deleted after use
- Ensure multiple instances of the procedure can use the same instance of the temp-table. A HANDLE field can be added to the temp-table to track which procedure instance owns a record.
- Ensure that there is only a single, reusable instance of the procedure
If static temp-tables are defined in classes, modify application code in one of the following ways (not mutually exclusive):
- Ensure that there is only a single, reusable instance of the class needed.
- Ensure temp-table a static member of the class. A Progress.Lang.Object field can be added to the temp-table to track which class instance owns a record).
- Ensure the class instances are deleted when no longer needed, either by making sure no references remain (so the instance can be garbage collected) or by deleting it explicitly with the DELETE OBJECT statement.
Define temp-tables with NO-UNDO. For further information refer to Article
Error "Attempt to update data exceeding 32000 . (12371)" raised when assigning a value to a variable If TABLE-HANDLE and/or DATASET-HANDLE parameters are used when the parameter is not BY-REFERENCE, a deep copy is made in order to marshal the schema and data to the called procedure.
- For INPUT and INPUT-OUTPUT *-HANDLE parameters in CALLED procedures you are responsible for deleting the handle reference before the procedure ends. The AVM is intelligent enough to delay the actual destruction of the object (temp-table or dataset) if the object is also used in an OUTPUT parameter. This is often done in a FINALLY block.
- For OUPUT *-HANDLE parameters you are responsible for deleting them before the calling procedure ends. The AVM is intelligent enough to delay the actual destruction of the object (temp-table or dataset) if the object is also used in an OUTPUT parameter. This is often done in a FINALLY block.
