KS DB Merge Tools logo KS DB Merge Tools
AccdbMerge logo for MS Access
aka AccdbMerge
KS DB Merge Tools for Oracle logo
KS DB Merge Tools for MySQL logo
MssqlMerge logo
KS DB Merge Tools for PostgreSQL logo
KS DB Merge Tools for SQLite logo
KS DB Merge Tools for Cross-DBMS logo

Known issues


Depends on MS Access

Application is using MS Access to read object definitions, merge objects and it can be used to process data. Sometimes Access registration can be broken and AccdbMerge stops working properly. You will get an appropriate message during the database open. Usually this can be fixed by the full repair of MS Office.

Linked tables

Application is designed to support linked tables only to Access files. It can support linked tables to other data sources, but it was not tested. You can report issues that some non-Access data source is not supported but we can't guarantee this issue will be fixed.

Merge and delete actions may fail

Failure can be caused by different reasons, for example foreign key constraints of some other dependencies. Please check the execution log.

Settings, diff profiles and multiple application instances

Application settings and diff profiles are saved as regular XML files. Before saving, the application does not check if any other changes could be made by any other application instance and can overwrite these changes.

Schema and data are processed separately

When you merge table definition, the application produces only table definition changes, it does not merge the data. Data needs to be merged separately if needed.

Mouse-driven interface

As a GUI application, it has most actions designed to be performed using a mouse. Application has some keyboard shortcuts, complex dialogs were adjusted to have expected tab order, but there was no comprehensive keyboard usability testing.

Documentation is not versioned

Application has online documentation, but it corresponds only to the latest application version. Sometimes documentation can be updated with delay. For our small dev team it is hard to support versioned documentation. However, the application is designed to support offline documentation and if you're a Pro active free-upgrades client then you may contact Support to get instructions to set up offline documentation.

Updates are backward-compatible but can be not rollback-tolerant

Application updates can be safely installed over the previous version, even with some gaps in the version sequence (for example install v 1.5.4 over 1.2.2). Any non-backward-compatible behavior changes are listed in the release notes. But the application is not designed to be downgradable. In most cases rollback to the previous version does not cause any issues. But in rare cases newer application settings may have some items which are not supported by previous versions and this may cause application crashes in case of rollback. In such cases application settings need to be deleted and for the Pro version license key should be entered again.

Schema and programming objects

Non-supported object types and object properties

If some object type or property is not presented on UI then most likely it is not supported. The example of unsupported object types are data access pages. Information about such objects and properties is not read from database metadata, not shown anywhere and can not be compared or synchronized. See How it works - Objects to get more information about which object types and properties are handled.

Table definitions false-positive changes caused by data macros

In the Pro version table definition is considered as changed if it has changed data macros XML, or if one side has data macros but the other side has no data macros at all. In some cases this may cause false positive changes if data macros XML is changed but these changes do not represent actual data macros changes. Please let us know if you're facing such an issue so we could provide a fix for your concrete case.


String keys and sorting on other data types which have no natural sort order

Application is using a sort-merge join algorithm to compare data in the regular tables with a common primary key ("common" means defined on the same columns with same data types). It requests data from both databases sorted by key, reads record by record and then compares these keys on the application side, expecting that comparison logic is the same on the application side and on both databases. This allows it to process huge amounts of data without significant memory impact on the application side. But that same-comparison-logic assumption is correct only for data types with a natural sort order, like numbers or dates. Particularly, this assumption can be wrong for some string collations. If database collations are different, or if application string comparison logic is other than database collation, then such cases can produce false-positive changes. If you think you face this issue, and if you use a Pro version - then you may try to use Query result diff to get better diff results. Query result diff does all sorting on the application side, which means that comparison logic will be the same for all steps of sort-merge join. But this approach has some limitations: it can't be used for large amounts of data and changes identified by Query result diff can not be merged.

Last updated: 2023-10-03