Database Compare Suite™

Known issues

Database Compare Suite has a number of known issues that you need to consider working with you database projects.

One-to-many matching

Database Compare Suite does not support one-to-many matching for data objects (tables, views, etc.) in data operations. You can apply multiple matching in data operation only to columns.


  • Data migration operation to Oracle is impossible if target table has names containing low case symbols.

  • Data migration operation to Oracle inserts NULL values into string columns instead of empty strings.

  • Data migration operation to Oracle is impossible for tables that have XML type column.

  • Synonym for a schema object specified with dblink type on a remote database is not loaded.

Sybase ASE

  • Currently the 64-bit version of the Database Compare Suite application cannot interact with the 32-bit Sybase OLE DB provider. The issue occurs if:

    • The host operation system is 64-bit.

    • The Database Compare Suite application is 64-bit.

    • Only 32-bit Sybase providers are installed on the host machine.

    In this case, Database Compare Suite application cannot correctly interact with Sybase database.

    To solve this issue, you have to install the 32-bit version of the Database Compare Suite application.

  • Some Unicode characters are not correctly processed:

    The character set model used by Adaptive Server® Enterprise (ASE) is based on a single, configurable, server-wide default character set, e.g. cp850, iso_1 etc. including UTF-8. All the data stored in ASE that is using any of the character data types (CHAR, VARCHAR, NCHAR, NVARCHAR, TEXT) is encoded using code point values of this server-wide character set complimented by a single configurable sort order.

    If the character is not represented in the code page (table of values that describes the character set) that corresponds to the server-wide character set used by default (e.g. cp850, iso_1), then Sybase converts the current character to ‘0x001A‘. As a result, the current character cannot be displayed in the database. The same behavior can be reproduced when the character’s codes are different on the code page and in the Unicode-table.

    For example:

    Server-wide default character set iso_1. Source data contains the character that has ‘0x80‘ code – in the code page and ‘U+20AC‘ code in the Unicode-table. When performing the Migration or Synchronization Data Operation to Sybase, the target database gets ‘U+20AC‘ character’s code that is not represented in iso_1 code page and converts current character to ‘0x001A‘ (Substitute). That is why character looks like an empty character in the target database.

    As an example, €‚ƒ„…†‡ˆ‰Š‹ŒŽ‘’“”•–—˜™š›œžŸ characters of ‘Western’ character set will be converted by Sybase to ‘0x001A‘.

  • NCHAR, NVARCHAR, UNICHAR, UNIVARCHAR, TEXT, UNITEXT columns are truncated to ’00’ symbol.

  • Long VarChar, Long NVarChar, and Long Binary Data types are supported only if the data size doesn’t exceed 32 kilobytes in Sybase IQ.


  • Data migration operation for the column with DECIMAL type inserts only NULL or 0 values if the first value in the source database is NULL.


  • Data migration operation may fail for big numeric (greater than maximum of .Net Decimal type) of “Numeric”, “Decimal” data types.


  • The data type for view columns is not loaded.

  • SQL for procedures is not loaded.

Sybase IQ

  • Data types Long VarChar, Long NVarChar, Long Binary are supported for data size < 32K.

  • Database Compare Suite doesn’t guarantee successful data migration if the number of columns in the migrated table exceeds 10000.


  • Database Compare Suite doesn’t guarantee successful data migration if the number of columns in the migrated table exceeds 1300.


  • When migrating to Vertica, Database Compare Suite doesn’t migrate columns with values that are not within an acceptable range. In this case, the operation completes without errors, depite the fact that the data hasn’t been migrated actually.

  • Vertica ODBC driver doesn’t support long verbinary type with a size exceeding 7500000 bytes.

Amazon DynamoDB

  • Database Compare Suite supports schema operations only for 2 Amazon DynamoDB databases. So, you can’t compare Amazon DynamoDB schema with another database platform.

  • You can use Amazon DynamoDB as a source for Data Synchronization and Data Migration operations only if target is also Amazon DynamoDB.

  • You can not exclude Amazon DynamoDB columns from operations.

Microsoft Access

  • The Schema Synchronization operation cannot create a column with INTEGER data type on Microsoft Access side. Instead of a column with LONG data type is created. Please, specify equality of INTEGER and LONG data types in the type mapping settings if you want to compare databases after the schema synchronization operation.

  • Database Compare Suite cannot open the Microsoft Access database if any table contains a column with BigInt datatype.

  • Microsoft Access does not return seed and increment of auto increment fields. Values (1, 1) are always used.

Displaying an exported result of the schema comparison operation

  • The exported result of the schema comparison operation is displayed incorrectly in the “Microsoft Edge” because it does not support XSLT.

Support dates and intervals greater than 9999 years and less than -9999 years

  • For PostgreSQL, Redshift, and Greenplum Database Compare Suite doesn?t support dates and intervals greater than 9999 years and less than -9999 years.

Fast data comparison for tables with columns of floating point data

  • The result of the Fast Data Comparison operation can be unpredictable for tables with columns of floating point data. Different database platforms have different precision for such type of data. So, in some situations, the result of a fast data comparison operation can be “Not Equal” even if data is really equal and usual data comparison or detailed data comparison operations return the right result “Equal”.

ADO.NET DateTimeOffset lower limit

  • ADO.NET DateTimeOffset type supports only values greater than or equal 1/1/0001 12:00:00 AM +00:00. The data is migrated incorrectly while attempting to convert values that are less than the lower limit of DateTimeOffset.

Didn’t find the answer?

You can report problems, ask questions or share ideas for improvements on our email [email protected].