On the server you apply the changes to the data source using the SAVE-ROW-CHANGES( ) method on the before buffer of the temp-table.

The following is the syntax for saving row changes for a temp-table buffer:

before-table-buffer-handle:SAVE-ROW-CHANGES().

The SAVE-ROW-CHANGES method validates the before-table record matches the current database record. If there is a match, it updates the database with corresponding after-table record values. It then repopulates the change dataset temp-table with data from the database. These changes could include automated changes made by database triggers or changes made by other clients.

If SAVE-ROW-CHANGES determines the before-table record does not match the current database record, it means that someone else has modified this record since it was read. Errors may be raised if the before-table record does not match or if the update does not succeed. You need to write code to handle these errors.

Transaction scope with SAVE-ROW-CHANGE

Since there is no method to save changes for an entire dataset or an entire temp-table, use SAVE-ROW-CHANGES at the row level. Since you are processing changes at the row level, you have complete control over the size and scope of each transaction. SAVE-ROW-CHANGES starts its own sub-transaction.

Define a large transaction

In some cases, it is desirable to have the transaction scoped at the individual record level. However, if your application requires a larger transaction scope (for example, updates all order data for an order in a single transaction), explicitly define the larger transaction using a TRANSACTION block.

Maintain database integrity

Depending on the relationships between your dataset tables, you may not be able to simply loop through each before-table in its entirety and perform SAVE-ROW-CHANGES on each row in turn. To maintain database integrity, you may have to process before-table records in a specific sequence across a group of tables (parent-child-child-child, next parent-child-child-child) and define a transaction scope that includes each logical grouping of tables. This processing enables you to roll back a transaction that spans multiple records in multiple tables if the update fails for any reason.

Manage change conflicts

While the save process can be very easy if you use the default behavior of the SAVE-ROW-CHANGES method, you may find that you need more control over the priority of changes when change conflicts are encountered. ABL datasets allow you to handle database change conflicts in a variety of ways.

Conflict resolution choices

Because the SAVE-ROW-CHANGES method supports an optimistic locking strategy, it is possible that another client may have modified a record since the dataset records were initially read. Depending on your business rules, you may want to do one of the following:

  • Reject the dataset changes in favor of the changes made by other users. This option copies the database record back to the change dataset which is returned to the client. This behavior is the default.
  • Reject the database changes made by others in favor of the dataset changes. This option is not recommended, so use with caution.

Detach the data-source

After the updates are processed, detach the data-sources using the DETACH-DATA-SOURCE( ) method. Detach the data-sources as soon as you are done with them. The following code example detaches the data-sources for ttOrder and ttOrderLine.

BUFFER ttOrder:DETACH-DATA-SOURCE( ).
BUFFER ttOrderLine:DETACH-DATA-SOURCE( ).

See also

Access a member buffer of a ProDataSet in Use ProDataSets