RepServer Mixed Character Sets

[Former Member]

We have source data in ASE with “cp850” charset and “nocase_cp850” sort order.

Replication server (currently) is cp850 and “nocase”.

There is a Warm Standby pairing setup to provide DR for the cp850 source.

We want to add a UTF-8 ASE instance into the mix, which will receive replicate data from the cp850 source.
We also need a “DR” for this UTF-8 instance.  At this time, however, there is no data going in to the UTF-8 instance except from RepServer (effectively it’s read-only to clients). There will be 350+ subscriptions feeding the UTF-8 instance though – so we ideally need the UTF-8 DR to be Warm Standby or MSA so we don't have to manage double the number of subscriptions!

We have 3 options to provide this (that we can think of) :

1.  Leave RepServer at cp850 and that populates the UTF-8 instance(s).

2.  Change the RepServer to use UTF-8

3.  Setup a UTF-8 RepServer fed via a route from the cp850 RepServer: the former feeds/replicates the UTF-8 instance; the latter does DR/Standby for the cp850 source

My questions on each of these options are:

1. If all the data (source) is cp850, does it matter that the “targets” are UTF-8 (which I think contains all the cp850 characters)? How will the MSA/WS replication of the UTF-8 instance work - through a cp850 RepServer – assuming that all the character data is cp850-compatible anyway?
2. Will the cp850 WS replication be OK going through a UTF-8 RepServer?
3. Will the cp850 to UTF-8 conversion happen ok between 2 RepServers on the different charsets? Which should be the ID server (currently the cp850 one is its own ID server)? Should both RSSDs be the same charset as their respective RepServers?

The manuals advise you to have all the character sets and sort orders the same across a replication system, but that's not an option here and I'm not sure what the "correct" way to ignore that advice is

[terry_penna · Accepted solution]

Antony

Here are the answers to your question.

1) Since your primary database is cp850 it will not matter that your targets are UTF-8.

2) There will be no issues with cp850 data going through a UTF-8 RS.

3) There should not be any conversion because UTF-8 will handle all cp850 characters and. If the RSSD of the second RS is in the new ASE it will be UTF-8 and this will not be an issue.  If you wanted you could build the new RS using an ERSSD and that would keep the RSSD out of the ASE.  We recommend building RS's with ERSSD's.

Bottom line if your primary data is cp850 and only cp850 then the new ASE and RS running UTF-8  will be fine and you will not have any character conversion issues.

Thanks

Terry

[Former Member · Accepted solution]

Hi Terry,

Testing this out in our lab, I have not found any data issues yet .. but there are warnings in the log:

W. 2015/10/12 17:11:28. WARNING #13092 DSI(104 ASEABSB04.test_ws) - seful/cm.c(8180)         The Data Server 'ASEABSB04' is using the 'cp850' character set for Database 'test_ws'. The Replication Server is using the 'utf8' character set. Unexpected results may occur. W. 2015/10/12 17:11:28. WARNING #13061 DSI(105 ASEABSB03.test_rep) - seful/cm.c(8094)         Server ASEABSB03 is using 'utf8_nocase' sort order, which is different from this Replication Server's sort order. W. 2015/10/12 17:11:28. WARNING #13092 DSI(103 ASEABSB04.test) - seful/cm.c(8180)         The Data Server 'ASEABSB04' is using the 'cp850' character set for Database 'test'. The Replication Server is using the 'utf8' character set. Unexpected results may occur. W. 2015/10/12 17:11:28. WARNING #13061 DSI(106 ASEABSB03.test_rep2) - seful/cm.c(8094)         Server ASEABSB03 is using 'utf8_nocase' sort order, which is different from this Replication Server's sort order.

Is this anything to be concerned about? Given that UTF8 includes all the characters of CP850 I would not expect any "unexpected" results?

[Former Member · Accepted solution]

To answer my own question (maybe) ... I guess this is because these are the replicate connections. RepServer has no way to know we are only going to replicate cp850 data. It only knows that the target is cp850 which cannot handle all the characters that *might* be sent through the RepServer which is utf8.

So although we know that the source is only going to be cp850 ... RepServer has know way of knowing what stupid things we might ask it to do - so issues a warning regardless. Makes sense I suppose.

- A

[terry_penna · Accepted solution]

Correct...

RS is just warning you that your character sets are differnt and that unexpected results may occur.  It is just a simple check and if they do not match we give the warning message.

Regards

Terry

[Former Member · Accepted solution]

Thanks Terry.

Is there any issue with the RepServer also having a different sort order (binary) compared to the source and target (nocase)?

We are not planning to use where-clauses in our subscriptions, only manual materialisation, and not using ASO ... so I guess under those circumstances the sort order should not make a big difference?

- A