Try OpenEdge Now
skip to main content
ProDataSets
Updating Data with ProDataSets : Tracking changes in the temp-tables of a ProDataSet : ROW-STATE attribute
 

ROW-STATE attribute

There is a ROW-STATE attribute on the temp-table buffer in both the after-table and the before-table to allow you to determine how, if at all, each record has been changed. ROW-STATE is an integer value representing one of these constants, which you can and should use to identify the meaning of the ROW-STATE:
*0=ROW-UNMODIFIED
*1=ROW-DELETED
*2=ROW-MODIFIED
*3=ROW-CREATED
Note that these are un-quoted literals that correspond to integer values, much like the values NO-LOCK, SHARE-LOCK, and EXCLUSIVE-LOCK for LOCK-MODE. You use the literals in ABL logic, in statements such as this:
IF hTTCust:ROW-STATE = ROW-MODIFIED THEN . . .
If you display the ROW-STATE, it is displayed as an integer.
Each record in the after-table that has been modified or added has an internal pointer to its counterpart in the before-table. These after-table records have a ROW-STATE value of ROW-MODIFIED or ROW-CREATED, depending on whether the row has been added to the temp-table since TRACKING-CHANGES was set to true. Deleted records do not appear in the after-table, because it reflects the current state of the data. Records in the after-table that have not been added or changed have a ROW-STATE of ROW-UNMODIFIED. These records have no counterpart in the before-table.
Every record in the before-table has a nonzero ROW-STATE because every record is the before-image for a deleted, created, or modified record. Records in the before-table can have a ROW-STATE equal to one of these values:
*ROW-DELETED — A deleted row in the before-table holds the original field values of the record at the time TRACKING-CHANGES was set to true. It has no counterpart in the after-table. A record is moved from the after-table to the before-table when it is deleted. Thus, the only way to locate deleted records is in the before-table. If a record is modified and then later deleted before changes are processed, then its state is ROW-DELETED and there is no record of the changes made before that.
*ROW-MODIFIED — A modified row in the before-table holds the field values of the record at the time that TRACKING-CHANGES was last set to true. The row is copied from the after-table when it is first changed. No intermediate changes between the "original" values and the latest values are saved anywhere.
*ROW-CREATED — A newly created row is created in the before-table at the same time that the equivalent record is created in the after-table. The before-table row for a created row does not hold any meaningful field values. It serves merely as a placeholder for the row so that you can identify created rows along with modified and deleted ones by looking at the before-table. The field values in the after-table can then be changed as the record is edited, just as for changed rows. The ROW-STATE remains ROW-CREATED until changes to the table have been processed, regardless of how many times field values have been modified in the meantime.
Records in the after-table can have a ROW-STATE of ROW-UNMODIFIED, ROW-CREATED, or ROW-MODIFIED. This means that new records and changed records can be tracked through either table. However, because deleted records are removed from the after-table, they can be tracked only through the before-table. In general, you should process changes through the before-table for this reason.
Note: Editing a record by replacing its value with the exact same value changes the ROW-STATE attribute changes to ROW-MODIFIED, in spite of the fact that the record's value remains the same. As a result, GET-CHANGES can return records that don't appear to have been changed.
* ROW-STATE function
* Special restrictions on TRACKING-CHANGES