Note that when setting errorAction to ROLLBACK or ROLLBACK_AND_STOP it is possible that the step may end up with an exception if it is not possible to set autocommit to off for the respective database connection. Nevertheless, for now, it seems to be a specific problem of some types of ODBC connections (writing to Excel files, for example). On all other connections it is possible to disable autocommit and therefore it is safe to set up the "rollback" errorAction.
|
Value |
Description |
|---|---|
|
ROLLBACK |
Should be used only with commitSize = 0 (all data in a single transaction). In that case either all data are written to the database (no problems found) or no data are written (all problem rows are sent to the error output err_out). When used with commitSize > 0, data of non-problematic commit blocks are written to the database. If there are some problematic rows in the commit block, then the problematic rows are sent to the error output but the commit block itself is rolled-back, so good rows of the commit-block are lost (they aren't in the database or in the error_output). It is recommended that this action be used only with commitSize = 0, since, in this case, the database will contain either all the data or none of it. |
|
ROLLBACK_AND_STOP |
Should be used only with commitSize = 0. The reasoning is the same as for ROLLBACK with the one exception - processing ends after the first error occurs. Rows following the error block are read but not processed. As result there are either all data in the database and an empty error output or no data in the database and one error record in the error output. Again, this is true only for commitSize = 0, as was discussed above. |
|
CONTINUE |
All data are written to the database except the rows causing writing problems. These rows are sent to the error output, err_out |
| iWay Software |