I have two datasets to compare: an original table and a revised table. I want to pass them through the UpdateDetector to track Updates, Inserts, and Deletes. The two tables are linked by a shared primary key attribute, and I want to track changes that may exist in another attribute; however, the original table has an extra attribute, ExtraID, which does not exist in the revised table. For features that exit the Updated port, this ExtraID loses its value. How do I retain the values in ExtraID and prevent them from exiting the UpdateDetector as NULL?
Solved
How do I compare tables with mismatching schemas when using the UpdateDetector?
+18- Safer
Best answer by nathanatsafe
Features exiting the Updated port of the UpdateDetector exist in both Original and Revised tables, but with some differences. Since the Revised features are the ones output, the UpdateDetector has no access to the Original ExtraID, and does not know it should retain the attribute.
One workaround that will rejoin the dropped ExtraID after the UpdateDetector involves the FeatureMerger:
Using a FeatureMerger, features from the Original can be routed to the Supplier port, while features exiting the Updated port in the UpdateDetector can be routed to the Requester port. Joining on the KeyID will line up both the Original and Updated features, and the ExtraID attribute is ‘supplied’ to the Updated features. The Merged port will have the desired output: the Updated features and their attributes, plus the original ExtraID that was not present in the Revised table.
+7- Safer
- Best Answer
Features exiting the Updated port of the UpdateDetector exist in both Original and Revised tables, but with some differences. Since the Revised features are the ones output, the UpdateDetector has no access to the Original ExtraID, and does not know it should retain the attribute.
One workaround that will rejoin the dropped ExtraID after the UpdateDetector involves the FeatureMerger:
Using a FeatureMerger, features from the Original can be routed to the Supplier port, while features exiting the Updated port in the UpdateDetector can be routed to the Requester port. Joining on the KeyID will line up both the Original and Updated features, and the ExtraID attribute is ‘supplied’ to the Updated features. The Merged port will have the desired output: the Updated features and their attributes, plus the original ExtraID that was not present in the Revised table.
Reply
Rich Text Editor, editor1
Editor toolbars
Press ALT 0 for help
Helpful Members This Week
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.