For a dynamic temp-table, a before-table is created only when the temp-table's TRACKING-CHANGES attribute (or the corresponding ProDataSet attribute) is first set to true. After that the before-table remains in existence for the life of the after-table, even as TRACKING-CHANGES is set to false and back to true.
When you pass a ProDataSet parameter, if the receiving procedure receives the ProDataSet as a dynamic object (as a DATASET-HANDLE), then the AVM automatically creates a before-table for each modified temp-table if one does not already exist.
In the case of a static temp-table that might be used to track changes as part of a ProDataSet, you must provide a static name for its before-table by naming it in the DEFINE TEMP-TABLE statement, as shown in the following syntax:
The AVM cannot create a before-table for you at run time as it does for dynamic tables. Procedure code can refer to the before-table by name as it does other temp-tables, except that any attempt to directly modify its records results in a run-time error. For a static definition, the before-table is instantiated along with the after-table, and you can freely refer to it in procedural code.
When you pass a ProDataSet parameter, if the receiving procedure receives the ProDataSet as a static object, then its static definition must include a static name for the before-table. Otherwise, the AVM does not create a before-table and raises an error. The following figure shows how the before-table and after-table are related.
Figure 11. Relationship of before- and after-tables
Actually, the before-table has a non-unique index on the ROW-STATE, so that changes are in order with delete operations first, then modify operations, and then create operations.
Both the before-table and after-table are part of the ProDataSet. They are passed together as part of the ProDataSet parameter and have the same scope and lifetime, with the exception that a before-table for a dynamic temp-table is created only when first needed.
The arrows illustrate the four states and their relationships:
1. When OrderLine 09 is modified, the before image is copied to a new record in the before-table. The ROW-STATE for both records is ROW-MODIFIED, represented by the M in the illustration. The ROW-STATE is not actually stored as a user-accessible temp-table column. It is accessible only through the ROW-STATE attribute.
2. When row 11 is created, a placeholder for it is created in the before-table. It serves only to log the creation and point to the record in the after-table.
3. When row 22 is deleted, it is removed from the after-table and moved to the before-table.
4. Rows 10 and 77 have a ROW-STATE in the after-table of ROW-UNMODIFIED, represented by the U. There is no corresponding row in the before-table.
