In most cases the default mapping mechanism that pairs the objects based on the schema name and the object name is what is needed. However, there are often scenarios in which the same table may be owned by different schemas in different databases, or the tables on the development server for example may have the names prefixed with dev_ whereas the same tables in the production server do not have that prefix. In such cases you may want to define certain mapping rules that would allow you to pair objects that would otherwise not be paired together.
The Mapping Rules can be accessed from the ribbon or from the action links on the right panel of the comparison tab.
There are three types of rules that you can set:
-
Schema Mapping Rules - by default data compare performs an exact match of the object schema, but you have two additional options:
- Ignore schema name - schema is not considered when tables or views are mapped with each other.
- Manually map the schema names - allows you to map the schemas between the source database and the target database. Two tables, for example, named dev.employees and prod.employees, by default, are not mapped with each, since they belong to different schemas. If you map the dev schema to the prod schema, these tables will be mapped.
- Name Mapping Rules - by default data compare performs an exact name matching of database objects. You can, however choose to ignore a leading portion of the name (prefix) or an ending portion of it (postfix). If you have databases where tables are prefixed, you can use this mapping rule to compare them.
- Data Type Mapping Rules - type mapping rule determines how columns are mapped with each other. Columns can only be compared if they have the "same" type. Depending on this rule, the type equality is determine either by the name, i.e. varchar-to-varchar, or by the compatibility matrix, i.e. varchar-to-char or varbinary(max) - image arte allowed. The compatibility matrix is built-in into the data compare and cannot be changed.
