GET-CHANGES method
- Last Updated: February 11, 2026
- 3 minute read
- OpenEdge
- Version 13.0
- Documentation
GET-CHANGES method
Syntax
The GET-CHANGES method extracts
the changes for you into a second ProDataSet, normally one that
you have just created using the CREATE-LIKE method. However,
there is nothing to prevent you from defining two equivalent ProDataSets
statically and using GET-CHANGES to move changes
from one to the other. If the target ProDataSet is static, it must
contain temp-tables whose field definitions are the same at least
in field data type, extent, and order. The temp-table index and
Data-Relation definitions do not need to match between the ProDataSets,
but the fields of the temp-tables must match in name, order, data
type, and extent.
We call the result of a GET-CHANGES method
a change ProDataSet. We refer to the original ProDataSet that acts
as the source for the change ProDataSet as the origin ProDataSet.
GET-CHANGES uses
the handles of the two ProDataSets, just as CREATE-LIKE does,
as shown in the following syntax:
|
GET-CHANGES effectively does
the following for each temp-table in the origin-dataset for
which there is a before-table:
- For each row in the before-table, it creates a row in the before-table of the change-dataset and buffer-copies the origin-dataset row into the change-dataset.
- For each before-table row that is not for a delete, it locates
the row in the after-table of the origin-dataset that
is paired with the row in the before-table (using the
AFTER-ROWIDattribute), creates a row in the after-table in the change-dataset, and buffer-copies the origin-dataset row to the change-dataset table. - Sets the
ROW-STATEof the change-dataset row to theROW-STATEof the origin-dataset row in the target-dataset before-table, and if applicable, the after-table. - Saves the
ROWIDof the before-table record in the origin-dataset as an attribute, calledORIGIN-ROWID, of the same row in the change-dataset. This can be used later to allow the final versions of changed rows to be merged into the original origin-dataset.
As the examples in Advanced Update Operations show, your
procedure can then pass the target dynamic ProDataSet as an INPUT-OUTPUT
parameter to the server-side procedure, get back the final versions of any records further
changed on the server, and merge them back into the original ProDataSet, using the
MERGE-CHANGES method.
If you want to include the parent row of each changed child row in the ProDataSet object or ProDataSet temp-table, use the optional get-parent-mode expression, as shown in the following syntax:
|
If there is more than one parent level above
the changed row, the AVM includes the parent row at each level.
In this case, the parent temp-tables must have a unique primary
index that the AVM can use to find the corresponding rows. If a
parent row has changed, the AVM copies both the before-image and after-image
of the parent row. If a parent row has not changed, there is no before-image
of the parent row, and its change state (ROW-STATE)
is ROW-UNMODIFIED(0) or the Unknown value (?).
When the relation mode of a parent is REPOSITION,
no attempt is made to find that parent.
When this expression is false, the AVM does not include parent rows. The default value is false.
The ProDataSet objects associated with the change-handle and original-handle must have the same number of temp-table buffers, and the definition of the corresponding temp-tables must match (that is, in the number of columns, data types, and so on).
Once
the changed rows are loaded, the AVM sets the ORIGIN-HANDLE attribute
on the temp-tables in the receiving ProDataSet object to the corresponding
temp-tables in the original source ProDataSet object. The AVM also
sets the ORIGIN-ROWID attribute on each of the
before-image table rows created in the receiving ProDataSet object
to the ROWID of the corresponding before-image
table row in the original source temp-table. The MERGE-CHANGES and MERGE-ROW-CHANGES methods
use these values to match up temp-tables and temp-table rows during
a merge operation.