All merge/delete statements are executed as SQL commands. That's convenient for action review and such scripts can be saved for later use. But large scripts (for example for huge blob values) can produce some issues. Application may fail with out-of-memory or it may exceed some limitations on the database engine. Even if the database engine provides an API to handle such blobs as stream, this API is not used by the application.
Failure can be caused by different reasons, for example foreign key constraints of some other dependencies. Please check the execution log.
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.
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.
Application has online documentation, but it corresponds only to the latest application version. Sometimes documentation can be updated with delay.
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.
Application is using some space in the user profile. It caches large strings, binary values and generated scripts. These temporary files are removed when no longer needed.
Since all merge actions are script-based, Access files can't serve as a merge/delete target. Not all Access features have SQL representation - for example SQL has no support for multi-value fields, both DDL and DML.
SQLite library version used to process SQLite files is 3.37.0. Application can open files created with later version of library, but if your database uses any SQLite features appeared in later versions, then such use can be ignored by application or even application may fail in some cases.
Application uses own SQLite object definition parser. Native SQLite parser can allow some statements which are not allowed according to SQLite docs, for example like this one. It may happen that such object definition would not be parsed by application correctly.
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: 2024-07-17
