Table definitions and views are by default identified by name. If both DBMS support schemas (i.e. Oracle, PostgreSQL, and SQL Server), the Standard version can be configured to identify objects by the combination of schema and name. If this option is disabled (which is the default), and the same object name is used in different schemas, those objects remain unmatched and are counted as new. Name comparison is case-insensitive, so for example table myTable vs MyTable is considered the same table.
Additionally, the Standard version supports advanced matching via Diff Profiles. You can define custom schema mappings (e.g., map hr_ prefix in SQLite to HumanResources schema in SQL Server) and name normalization rules (e.g., automatically match tblUserLocations and user_location by stripping prefixes/suffixes). These settings override the basic 'match by schema' option and enable reliable comparison across databases with different naming conventions.
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 Standard 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, indexed columns and name of the index. If no match is found, then the application tries to find a matching index by the table 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 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 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.
