This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(176, 89%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ESA%3C/text%3E%3C/svg%3E)
What is the server collation of the two instances? What is the collation of the distribution database?
server collation: SQL_Latin1_General_CP1_CI_AS
Distribution database : SQL_Latin1_General_CP1_CI_AS
I don't work that much with replication, and I am not inclined to set up a test. However, I have a feeling that the server collation is the culprit here. Or maybe it is the collation of the distribution database. But I suspect that distribution simply inherits the system collation.
If possible, I would suggest that you make a setup where the server collation is a UTF8 collation.
The above is the work around for the above issue i know that, but actual question why i am facing this issue while using varchar data type. For nvarchar data type there is no problem.
My customer is asking why varchar data type is not working properly in the replication and he is state it as a bug. If not, he is asking for the relevant document that states that varchar data type will not support for the UTF8 collation.
The issue is that the code page for SQL_Latin1_General_CI_AS is 1252, which is not the same as UTF8. For nvarchar, the mix of code pages is not an issue, but for varchar it is.
As I said, I don't work a lot with replication, but I know quite a bit about collations. It seems conceivable that there would be conversion twice here. Say that we have the value räksmörgås which is 13 bytes in UTF-8. It may be converted to räksmörgås in CP1252 which is only ten bytes when it passed to the distribution database, and then it would be converted back to 13 bytes when sent to the subscriber.But note that this would not work for the value αβγδ, because the Greek characters are not available in CP1252.
What actually seems to happen here is that conversion only happens in one direction. This could be because the data land in the distribution database as log records, and since they are binary, no conversion happens.
Later when the data is sent to the subscriber, it is incorrectly interpreted as Latin-1 and therefore converted to UTF-8 once more.
In any case, I am quite confident that for replication of varchar to work, you need to have the same code page all the way from the publisher to the subscriber, including distribution.
If your customer insists on that this is a bug, please ask them to show the documentation that says that this setup is guaranteed to work.
This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.
Comments have been turned off. Learn more