A unit of work is one or more requests that execute, commit, or roll back as a group. Following are descriptions of a unit of work for bulk copy and destination-template transfer.
Unit of work is based on the setting of the BulkCommitCount property.
If BulkCommitCount is set to 0, the entire transfer is treated as a unit of work. The DB2 access service performs a commit after the last row of data is inserted into the target table, even if value errors occurred for individual rows of the transfer.
If BulkCommitCount is set to a non-zero value, each block of BulkCommitCount rows is treated as a unit of work. The DB2 access service issues a commit after each block of BulkCommitCount rows. For example, if BulkCommitCount is set to 50, each block of 50 rows is treated as a unit of work, and a commit is issued after each 50 rows.
For information about value errors, see the section “Value errors”.
When a destination-template transfer statement moves data from ASE to DB2 UDB, the DB2 access service automatically sets the StopCondition property to none. Subsequent commit and rollback processing is determined by whether short or long transactions are in effect:
If short transactions are in effect, the DB2 access service issues a commit after each batch, whether or not errors occurred in the request. In this case, each batch of inserts is a unit of work.
If long transactions are in effect, the DB2 access service issues a commit at the end of the entire transfer. Because StopCondition is set to none, the DB2 access service never issues a rollback. In this case, the entire transfer is a unit of work.
