When we use the update strategy transformation we have the option to reject the row based on a criteria. We usually use DECODE or IIF to specify the criteria for rejecting the row[Treat Source Row should be selected as Data Driven at the session level]
IIF( ( RESIDENT_SK=0), DD_REJECT, DD_UPDATE )
The following table lists the constants for each database operation and their numeric equivalent:
Insert | DD_INSERT (Numeric Value 0) |
Update | DD_UPDATE (Numeric Value 1) |
Delete | DD_DELETE (Numeric Value 2) |
Reject | DD_REJECT (Numeric Value 3) |
Now coming to the Forwarding Rejected Row Option in update strategy, this option is used to forward the rejected rows into the bad file which we define at session level. If you disable this option, the rejected records won't be available in the bad file (reject file).
However the rejected rows will be available in session log (Normal logging level) even though the forwarding rejected row option is enabled\disabled.
These records in the reject file help us to understand the reason for rejection and validate the records not satisfying the business requirement. This helps to change the input data the next time we load the target
Structure of Informatica Bad Files or Reject Files
There are two types of Indicators in the reject file. One is the Row Indicator and the other is the Column Indicator.
List of Values of Row Indicators:
Row Indicator | Indicator Significance | Rejected By |
0 | Insert | Writer or target |
1 | Update | Writer or target |
2 | Delete | Writer or target |
3 | Reject | Writer |
4 | Rolled-back insert | Writer |
5 | Rolled-back update | Writer |
6 | Rolled-back delete | Writer |
7 | Committed insert | Writer |
8 | Committed update | Writer |
9 | Committed delete | Writer |
0 Response to "Use of the property FORWARDING REJECTED ROWS in an Update Strategy transformation??"
Posting Komentar