When you configure a session, you can log row errors in a central location. When a row error occurs, the Integration Service logs error information that lets you determine the cause and source of the error. The Integration Service logs information such as source name, row ID, current row data, transformation, timestamp, error code, error message, repository name, folder name, session name, and mapping information.
You can log row errors into relational tables or flat files. When you enable error logging, the Integration Service creates the error tables or an error log file the first time it runs the session. Error logs are cumulative. If the error logs exist, the Integration Service appends error data to the existing error logs.
You can log source row data from flat file or relational sources. Source row data includes row data, source row ID, and source row type from the source qualifier where an error occurs. You cannot log row errors from XML file sources. You can view the XML source errors in the session log.
The Integration Service cannot identify the row in the source qualifier that contains an error if the error occurs after a non pass-through partition point with more than one partition or one of the following active sources:
Aggregator
Custom, configured as an active transformation
Joiner
Normalizer (pipeline)
Rank
Sorter
By default, the Integration Service logs transformation errors in the session log and reject rows in the reject file. When you enable error logging, the Integration Service does not generate a reject file or write dropped rows to the session log. Without a reject file, the Integration Service does not log Transaction Control transformation rollback or commit errors. If you want to write rows to the session log in addition to the row error log, you can enable verbose data tracing.
When you log row errors, session performance may decrease because the Integration Service processes one row at a time instead of a block of rows at once.