You can replace most of the code that follows the RUNupdateOrder.p statement in the BtnSave CHOOSE trigger with a single call to MERGE-CHANGES. In this case, you can apply all the changes back to the original ProDataSet with a single method call:

  1. Comment out or remove all the code in the CHOOSE OF BtnSave trigger starting at the CREATE QUERY statement and ending with the end of the DO WHILE AVAILABLE block.
  2. Replace this with the MERGE-CHANGES method on the ProDataSets to merge changes in the change ProDataSet hDSChanges back into the origin ProDataSet whose handle is hDSOrder.
  3. Remove the ACCEPT-CHANGES method later in the trigger. MERGE-CHANGES does the work of ACCEPT-CHANGES, or in the case of a failed update, REJECT-CHANGES, as shown: 
    /* MERGE-CHANGES would go here and replaces all this code. */
/* CREATE QUERY hQuery.
. . .
  hQuery:GET-NEXT().
END.  /* END DO WHILE AVAILABLE */
-- end of code replaced by MERGE-CHANGES. */

hDSChanges:MERGE-CHANGES(hDSOrder).

    MERGE-CHANGES replaces all the code that builds a dynamic query on the change ProDataSet's before-table, walks through it, finds the corresponding rows in the origin ProDataSet table, and copies final field values back into the origin ProDataSet. In addition, if there were any errors, MERGE-CHANGES would reject those changes by restoring the origin ProDataSet rows back to their state before the update was attempted. Using MERGE-CHANGES, you do not need to worry about using ORIGIN-HANDLE and ORIGIN-ROWID, following the chain of ROWIDs to the AFTER-ROWID, and so forth. The attributes are there for you to use only when you need to do something different from what MERGE-CHANGES does for you in a single statement.

    Use the high-level methods like SAVE-ROW-CHANGES and MERGE-CHANGES whenever you can to take advantage of all the programming steps they take care of for you. However, don't hesitate to code your own alternatives when the default behavior is not what you need in a particular situation.