Using wildcards to map object names
The following table shows how you might use wildcards to perform specific object-mapping tasks:
Example | Description |
|---|---|
SourceTable=TEST.* TargetTable=PROD.* | This example maps all of the tables owned by the TEST user ID to the equivalent tables owned by the PROD user ID. |
SourceTable=AP1.DS* TargetTable=AP1.AT* | This example represents data migration between tables owned by the application AP1. Tables that start with DS will be mapped to tables that start with AT. |
SourceTable=AP2.WK?? TargetTable=AP3.WEEK | This example shows how data from one or more source tables can be applied to a single target table. If the input file included updates from tables AP2.WK01, AP2.WK02, and AP2.WK22, those updates would be applied to the AP3.WEEK table. Because of the single-character wildcards, updates from table AP2.WK101 would not be applied to the AP3.WEEK table. |
Wildcards specified for the source object must match the type and format of the wildcards specified for the target object. The following table describes examples of valid and invalid mappings:
Example | Valid/invalid | Notes |
|---|---|---|
SourceTable=ACCT.WE?? TargetTable=ACCT.AT?? | Valid | The wildcards are the same type (single character) and format. |
SourceTable=*.SALARY TargetTable=???.RATE | Invalid | The wildcards are not the same type. The pattern for the source table is a string, but the pattern for the target table is three single characters. |
SourceTable=??.SALARY TargetTable=???.RATE | Invalid | The wildcards are not the same format. The different lengths render this mapping invalid. |
SourceTable=*.R??? TargetTable=*.JED??? | Valid | The wildcards are the same type and format. Note that the constants do not need to be the same length for the mapping to be valid. |