DataFlux Data Management Studio 2.6: User Guide
Conflicts are created in a data job when the field mappings between two nodes no longer match. This can happen if the fields in the source node are changed, but the fields in the target node are not updated to match. For example, the next display shows a source node (Data Source 1) that supplies fields to a target node (Basic Pattern Analysis).
If the fields in (Data Source 1 are changed, but the fields in Basic Pattern Analysis are not, then conflicts arise. You can use the Field Name Conflict dialog to resolve field name conflicts. The dialog is displayed whenever changes to a node in a data job create a conflict with another node that follows it in the data job.
Perform the following tasks to resolve field name conflicts:
Suppose that you have a job with the flow shown in "Overview" above, where a Data Source node sends fields to the Basic Pattern Analysis node. (These fields come from the Client_Info table.) Both nodes are processed successfully when you run the data flow. However, a field name conflict is created when you change the input table in the Data Source node (to NC_Customer, for example). The Field Name Conflict dialog appears, as shown in the following display:
The fields listed here are present in the descendant node (Basic Pattern Analysis), but they are not available in the input table selected for the Data Source node. This conflict between the fields in the two nodes can prevent the successfully completed processing of the descendant node.
In this case, the four field name conflicts are identified and resolved in the following ways:
After you set these options, click OK to close the dialog and save your selections. The next task is to update the descendant node.
You must open the descendant data job node (Basic Pattern Analysis, in this case) and adjust the field name settings before you can run the data job successfully. You can see the impact of the Field Name Conflict dialog on the second node in the following display:
The Available field contains the field names from the new input table (NC_Customer), while the Selected field contains the field names from the original input table (Client_Info). You can easily see that original table contained three fields that not found in the replacement table. These fields (Phone, Product, and Purchase Date) are listed at the end of the Selected field. The other impact is a little harder to see: the STREET_ADDRESS field name is matched to the Address_BasicPattern, thus preserving the name of the original input name in the output name.
Caution: You need to remove the three extra fields. If you do not, you will receive Parent field not found errors and the job will not complete successfully. You also want to preserve the Address_BasicPattern output name. Therefore, highlight the Phone, Product, and Purchase Data field names and click Remove, as shown in the following display:
If you do not care about preserving the Address_BasicPattern output name, simply remove all of the fields from the Selected field and replace them with all of the fields from the Available field. The sample job completes successfully when you use either approach.
Documentation Feedback: yourturn@sas.com
|
Doc ID: dfU_T_ResolveFieldNameConflict.html |