In summary Dbvisit Replicate does not rely on any NLS variables to function properly.
It does not depend on any NLS setting in the user's environment. Rather, it overwrites NLS_LANG at the session level and so should not depend on any implicit conversion, meaning that it is not affected by any other environmental settings.
The value of APPLY.NLS_LANG AMERICAN_AMERICA.AL32UTF8 is used to set the environment variables.
Dbvisit Replicate uses APPLY.NCHARSET to understand what NCHARSET the source database is using, either UTF-8 or UTF-16. Dbvisit Replicate will then convert the data to match the target NCHARSET.
With the non Oracle database (MySQL and MSSQL), the connections are set to use Unicode only (UTF-8 for MySQL and UTF-16 for MSSQL) - and then the data is converted according to NCHARSET to the format expected by the target db connection.
Replicating data between environments having different character set can be tricky sometimes, we have to make sure the columns having values other than the default character values( For example columns having Chinese characters) are handled properly. Conflicts will occur during these scenarios .
| Note |
|---|
Below is a example. Source characterset : ZHT16MSWIN950 Initial replication fails with error "Error: ORA-12899: value too large for column "SCOTT"."TAB2"."COL2" (actual: 106, maximum: 100)" After changing the target to CHAR(150) the replication runs fine. But when value is deleted in source the conflict arises again for zero rows conflict since it |
The solution for the problem is specifying datatype using NCHAR or NVARCHAR , we can also use length using "CHAR(100 CHAR)" . It says it should fit 100 characters, not 100 bytes. This should avoid any issues with character sets.