Database Compare Suite has a number of known issues that you need to consider working with you database projects.
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.
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.
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.
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.
The exported result of the schema comparison operation is displayed incorrectly in the “Microsoft Edge” because it does not support XSLT.
For PostgreSQL, Redshift, and Greenplum Database Compare Suite doesn?t support dates and intervals greater than 9999 years and less than -9999 years.
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 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.