Comparison in Error Handling

Data Exchange 5.0 provides more flexibility in the way runtime errors can be handled. The following table lists the difference in the way errors are handled in the two versions of Data Exchange:

Error Type	Data Exchange 4.0	Data Exchange 5.0
Transform Error (detected in Data Exchange and controlled by the transformation recovery settings)	These were set in the Development Workbench, by Runtime Error Handling Policy. Options are to Stop (default) Truncate or Reject These errors are detected before data is applied to the target data store. The errors are logged in the log file <Runtime Service Installation Path>/Log/DataLossLog.txt. Example 1 Assume that you have defined a mapping from a numeric (10,3) source data type to a numeric (4) target data type, and the source value is “50000.123”. If the target data type cannot hold any decimal values, then the Data Exchange Runtime truncates the decimal value and tries to save the integer value (50000) in the numeric (4) target data type. Assume that the maximum value that the numeric (4) target data type can hold is 9999. In this case, the Data Exchange Runtime rejects the source value (50000.123) from being transformed. However, if the target data type was numeric (5), then the Data Exchange Runtime would have successfully stored the integer part (50000) after truncation of the decimal values. Example 2 Assume that you have defined a mapping from an alpha (10) source data type to a char (3) target data type, and the source value is “ABCDEFG”, then the Data Exchange Runtime truncates the string value and tries to save the string value (“ABC”) in the char (3) target data type. In case of a mapping from a string data type to a target string data type, the "Reject" scenario will not occur. Example 3 Assume that you have defined a mapping from an alpha (10) source data type to a numeric (4) target data type, and source value is “50000.ABC”, then the Data Exchange Runtime tries to convert the source value “50000.ABC” to a numeric value first. But, in this case, “50000.ABC” is not a valid numeric string. Therefore the data will be rejected. Example 4 Data Exchange supports defining expression for Filter and DML Command Substitution. Take the expression ConvertToInt64(<<Name>>)>10 as an example. If the value of the column Name is “JIM” then Data Exchange will encounter a filter error or DML command substitution error because “JIM” is an invalid numeric value.	These are set in the Development Workbench, by Data Transform Error Handling Policy. Options are to Stop (default) Truncate or Reject These errors are detected before data is applied to the target data store. The errors are logged in the log file <Runtime Service Installation Path>/Log/DataTransformErrorLog.txt
NULL Handling	Data Exchange does not convert a NULL value. Therefore, target column will get a NULL value. However, if the target column is set to not Allow Null, then, an error will be logged in the log file <Runtime Service installation path>/Log/DataExchangeRuntimeServiceLog.txt.	Data Exchange provides the Target Commit Error Handling Policy, “Not Null Constraint Violation Error” to configure how to handle this error. If you set its option to Ignore, then the error is logged in the log file <Runtime Service installation path>/Log/TargetCommitErrorLog.txt.
Primary Key Violation	These are detected but are classified as Target Commit Error as they happen when the data is applied to the target database.	Handled as in 4.0, but the error handling can be set in Target Commit Error Handling Policy.
Target Connection Error	Set in the Administration Site, Recovery tab. Settings -> Recovery -> On Transformation Target Update Failure Retry 3 times (default) Retry 5 times Retry 10 times Stop Immediately Keep Retrying	Set in the Administration Site, Recovery tab. Settings -> Recovery -> On Transformation Target Connection Failure Retry 3 times (default) Retry 5 times Retry 10 times Stop Immediately Keep Retrying
Target Commit Error	Error handling for target commit errors are limited.	Handled by Target Commit Error Handling Policy (set in the CDT / BDT startup wizard in Administration Site). Options are to Stop (default) Ignore Retry 3 times (default and only available for Deadlock Error) The errors are logged in the log file <Runtime Service installation path>/Log/TargetCommitErrorLog.txt. Using this feature a commit error can be ignored. For example, if this is set to stop, then a commit error would stop the transformation. But, if it is set to ignore, you can get past the error and continue the transformation.