Validation checks

Recommendation: The discrepant column should always be selected as a column that is present in the listing.
Rationale: When you select the Discrepant Table and Column for a validation check, DMW allows you to select any table and column, not just the ones that make sense in the context of the validation check.

Parent topic: Validation checks

Recommendation: In a VC listing, do not rename the columns. Instead, use the default Oracle name of the underlying data model column for the column names.
Rationale: Renaming columns in a VC listing can lead to validation check performance issues, and the inability to modify the validation checks.
Additional information: You might need to rename columns if:
- Column names are not unique.
- You need to handle self-referencing queries.
In these cases, renaming is allowed.

Parent topic: Validation checks

Recommendation: Before you copy a validation check batch, to make sure that it's valid, verify that the columns in the source data model exist in the target data model.
Rationale: DMW allows you to copy a validation check batch that does not have valid columns in the destination data model. We recommend that you ensure that the validation check is valid before you copy it.
Additional information: We recommend that you only copy validation checks from approved templates or study libraries. In addition, if a validation check is deprecated, we recommend that you put in place a documented process to make sure that they aren't propagated to other studies.

Parent topic: Validation checks

Recommendation: Avoid copying validation checks that are disabled or that require an upgrade.
Rationale: Validation checks that require an upgrade might not include necessary columns from the data models, or have other un-resolvable issues.
Additional information: We recommend that you only copy validation checks from approved templates or study libraries. In addition, if a validation check is deprecated, we recommend that you put in place a documented process to make sure that they aren't propagated to other studies.

Parent topic: Validation checks

Recommendation: Copy blinded validation checks to blinded tables and non-blinded validation checks to non-blinded tables.
Rationale: Columns in a VC listing retain the blinding properties of their underlying data model. If there is a mismatch between the blinding of the validation check and its tables, DMW will report errors.
Additional information: We recommend that you define libraries with a blinded and unblinded validation check definition. You can then copy the validation check with the appropriate blinding setting for your purposes.

Parent topic: Validation checks

Recommendation: If you need to remove all of the columns in a table from a validation check, do not modify the validation check. Instead, disable the existing validation check and create a new validation check that excludes the table.
Rationale: The validation check program does not gracefully remove source tables when you update the validation check.

Parent topic: Validation checks

Recommendation: When you create a validation check, do not include columns from staging tables as its source.
Rationale: Staging tables are intermediate steps in a data transformation. They are not intended to be used to raise discrepancies.
Additional information: If you use staging tables, we recommend that you use them to explicitly define the intermediate tables in a separate staging model, as specified in the Guidance for DMW Implementation and Configuration document.

We don't recommend using staging tables due to the limitations of the feature.

Parent topic: Validation checks