Table definitions and views are by default identified by name. If both DBMS have both schema and name (it is Oracle, PostgreSQL and SQL Server), then the Pro version can be configured to identify objects by combination of schema and name. If this option is disabled (that's the default) and if the same object name is used for different schemas then these objects remain unmatched and counted as new. Name check is case-insensitive, so for example table myTable vs MyTable is considered as the same table.
All objects are built by reading object properties from different system metadata tables and views. Application reuses object reading logic from DBMS-specific products, so you can find more details about object definition reading in the 'How it works - Schema' section of documentation for corresponding tool:
Each supported DBMS uses its own set of data types. KS DB Merge Tools for Cross-DBMS calls these data types as native data types. To be able to compare some native data type with some other native data type from a different DBMS, KS DB Merge Tools for Cross-DBMS introduces the concept of generic data type: it is Number, String, Binary, Boolean, DateTime and Other. For example, a column of MySQL DECIMAL data type can be compared with a value of PostgreSQL smallint because both of these types are mapped to the Number generic data type. Other data type can not be compared with each other. See the Data types section to get more details about data type mapping.
Table definition is considered as changed if it has changed data columns (including order changes) or primary key columns. Data columns are identified by column name, generic type and nullability. The Pro version also allows to visually compare native but native type changes do not affect identification of the table definition changes. Primary key columns are identified by column names and order.
Indexes are identified by the combination of table name, indexed columns and name of the index. If no match is found, then the application tries to find a matching index by the table name and columns only (without index name). Index is counted as changed if it has changed Unique flag or index name. Index name is recognized as changed if index was matched by table name and columns, without an index name.
Application does not show indexes supporting primary keys because the PRIMARY KEY definition is already included in the table definition. If DBMS makes no difference between constraint and index supporting such constraint, then such index may be excluded as well (for example, MySQL UNIQUE constraints/indexes). The reason is that such constraints are also going to be included in table definition.
Foreign keys are identified by name of the child table and its columns used for the foreign key definition. Foreign key is counted as changed if it has changed parent table, its columns, or on update/delete actions.
Starting with version 1.7.0, the view is counted as changed if it has changed columns and/or their generic types, the same way as for table definitions. Before version 1.7.0 view was counted as changed if it has changed CREATE VIEW definition text. Obviously, this makes almost any view counted as the same to be considered as changed because of DBMS-specific syntax changes.
Last updated: 2024-07-16
