<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>Question Re: dbremote on windows + linux (Character encoding problem) in Technology Q&amp;A</title>
    <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824124#M4854967</link>
    <description>&lt;P&gt;"ß" won't be a problem in CH, right?&lt;/P&gt;</description>
    <pubDate>Mon, 16 Sep 2013 10:01:33 GMT</pubDate>
    <dc:creator>VolkerBarth</dc:creator>
    <dc:date>2013-09-16T10:01:33Z</dc:date>
    <item>
      <title>dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaq-p/13824120</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;P&gt;we use SQL Anywhere 10.0.1.4103.&lt;/P&gt;
&lt;P&gt;The consolidate server is running under windows and a most of the remote sites are running windows too.
We have recently added a few linux remotes, but there we see a replication problem with some characters.&lt;/P&gt;
&lt;P&gt;When a windows remote enter text in the database, sometimes the replication fails on the linux systems with this message:&lt;/P&gt;
&lt;DIV class="codehilite"&gt;&lt;PRE&gt;&lt;SPAN class="n"&gt;I&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;2013&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;00&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="n"&gt;INSERT&lt;/SPAN&gt; &lt;SPAN class="n"&gt;INTO&lt;/SPAN&gt; &lt;SPAN class="n"&gt;DBA&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;CardEntries&lt;/SPAN&gt;&lt;SPAN class="p"&gt;(&lt;/SPAN&gt;&lt;SPAN class="n"&gt;CardEntries&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;ClientCard&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;CreationDate&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;Amount&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;
                              &lt;SPAN class="n"&gt;REMOTENAME&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;Salesperson&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;EntryProcessed&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;BatchID&lt;/SPAN&gt;&lt;SPAN class="p"&gt;)&lt;/SPAN&gt;
                        &lt;SPAN class="n"&gt;VALUES&lt;/SPAN&gt; &lt;SPAN class="p"&gt;(&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'O000CB'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'J001UW'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'12:26:15.446918 2013/08/30'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;169&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'SiteTest1'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'Sil Sch.r'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;0&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;NULL&lt;/SPAN&gt;&lt;SPAN class="p"&gt;)&lt;/SPAN&gt;
&lt;SPAN class="n"&gt;E&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;2013&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;00&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="n"&gt;SQL&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="n"&gt;Anweisung&lt;/SPAN&gt; &lt;SPAN class="n"&gt;fehlgeschlagen:&lt;/SPAN&gt; &lt;SPAN class="p"&gt;(&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;131&lt;/SPAN&gt;&lt;SPAN class="p"&gt;)&lt;/SPAN&gt; &lt;SPAN class="n"&gt;Syntaxfehler&lt;/SPAN&gt; &lt;SPAN class="n"&gt;bei&lt;/SPAN&gt; &lt;SPAN class="s"&gt;'Sil Sch.,0,NULL)'&lt;/SPAN&gt; &lt;SPAN class="n"&gt;in&lt;/SPAN&gt; &lt;SPAN class="n"&gt;Zeile&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;3&lt;/SPAN&gt;
&lt;SPAN class="n"&gt;E&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;2013&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;00&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="n"&gt;Wird&lt;/SPAN&gt; &lt;SPAN class="err"&gt;ü&lt;/SPAN&gt;&lt;SPAN class="n"&gt;bersprungen:&lt;/SPAN&gt;
&lt;SPAN class="n"&gt;E&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;2013&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="o"&gt;-&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt; &lt;SPAN class="mi"&gt;09&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;03&lt;/SPAN&gt;&lt;SPAN class="p"&gt;:&lt;/SPAN&gt;&lt;SPAN class="mo"&gt;00&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt; &lt;SPAN class="n"&gt;INSERT&lt;/SPAN&gt; &lt;SPAN class="n"&gt;INTO&lt;/SPAN&gt; &lt;SPAN class="n"&gt;DBA&lt;/SPAN&gt;&lt;SPAN class="o"&gt;.&lt;/SPAN&gt;&lt;SPAN class="n"&gt;CardEntries&lt;/SPAN&gt;&lt;SPAN class="p"&gt;(&lt;/SPAN&gt;&lt;SPAN class="n"&gt;CardEntries&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;ClientCard&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;CreationDate&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;Amount&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;
                              &lt;SPAN class="n"&gt;REMOTENAME&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;Salesperson&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;EntryProcessed&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;BatchID&lt;/SPAN&gt;&lt;SPAN class="p"&gt;)&lt;/SPAN&gt;
                        &lt;SPAN class="n"&gt;VALUES&lt;/SPAN&gt; &lt;SPAN class="p"&gt;(&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'O000CB'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'J001UW'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'12:26:15.446918 2013/08/30'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;169&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'SiteTest1'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="s"&gt;'Sil Sch.r'&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="mi"&gt;0&lt;/SPAN&gt;&lt;SPAN class="p"&gt;,&lt;/SPAN&gt;&lt;SPAN class="n"&gt;NULL&lt;/SPAN&gt;&lt;SPAN class="p"&gt;)&lt;/SPAN&gt;
&lt;/PRE&gt;&lt;/DIV&gt;


&lt;P&gt;The "offending" text is the entry for the sales person which should be "Sil Schär",
but apparently it stumbles over the ä character.&lt;/P&gt;
&lt;P&gt;All databases have the same encodings:&lt;/P&gt;
&lt;P&gt;CHAR Collation: 1251LATIN1&lt;/P&gt;
&lt;P&gt;CHAR Encoding: windows-1252&lt;/P&gt;
&lt;P&gt;NCHAR Collation: UCA&lt;/P&gt;
&lt;P&gt;NCHAR Encoding: UTF-8&lt;/P&gt;
&lt;P&gt;The replication is done via Email.
In the connection string of dbremote we specify nothing special,
only uid,pwd,eng,dbn&lt;/P&gt;
&lt;P&gt;I think that the linux dbremote is using a wrong character set when deconding the
emails received and then trys to apply the sql operation in a wrong encoding.&lt;/P&gt;
&lt;P&gt;Strange is, that messages with the ü character are correctly replicated, but the ä seems to cause problems....&lt;/P&gt;
&lt;P&gt;Any ideas how to solve it ?&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 09:50:15 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaq-p/13824120</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2013-09-16T09:50:15Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824121#M4854964</link>
      <description>&lt;P&gt;Here's a note to SQL Remote and charsets from the &lt;A href="http://search.sybase.com/kbx/changerequests?bug_id=730270"&gt;newest v12 EBF (3942)&lt;/A&gt;.&lt;/P&gt;
&lt;P&gt;In my understanding, it doesn't describe a bugfix but a "how to" - and possibly that might work for you, too:&lt;/P&gt;
&lt;PRE&gt;    ================(Build #3850  - Engineering Case #730270)================

SQL Remote always assumes that all databases involved in replication share 
    the same character set. By default, SQL Remote will always apply source CHAR 
    data to a target database using the default character set for the operating 
    system it is running on, ignoring the source data character set.

When using a database character set that is different than the default character 
    set for the operating system, dbremote must be instructed to perform explicit 
    data conversion to that character set on its connection string:

e.g. dbremote -c “CHARSET=utf8;…”

or instruct dbremote to always use the CHAR character set 
    of the target database to apply the remote CHAR data:

e.g. dbremote -c “CHARSET=none;…”

&lt;/PRE&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:00:16 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824121#M4854964</guid>
      <dc:creator>VolkerBarth</dc:creator>
      <dc:date>2013-09-16T10:00:16Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824124#M4854967</link>
      <description>&lt;P&gt;"ß" won't be a problem in CH, right?&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:01:33 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824124#M4854967</guid>
      <dc:creator>VolkerBarth</dc:creator>
      <dc:date>2013-09-16T10:01:33Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824122#M4854965</link>
      <description>&lt;P&gt;I think you are right. Something is likely interpreting the data as UTF8 on Linux. In cp1252, 'ä' is encoded as 0xE4 which introduces a 3-byte character and that will end up gobbling up the 'r' and the closing quote as part of that character. That's why you see the syntax error. In cp1252 'ü' is encoded as 0xFC which is not a valid lead byte (or follow byte for that matter) so it just gets passed through as a single byte and doesn't cause problems.&lt;/P&gt;
&lt;P&gt;I don't know anything about the dbremote or email side of things though. I expect that the emails being sent don't have the encoding specified in the header and therefore the other side is assuming OS charset? Perhaps you can add such a header yourself?&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:02:55 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824122#M4854965</guid>
      <dc:creator>johnsmirnios</dc:creator>
      <dc:date>2013-09-16T10:02:55Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824123#M4854966</link>
      <description>&lt;P&gt;Try adding "charset=none" in the connection string for dbremote on all nodes.  John's comment that dbremote is assuming OS charset when reading a message is correct, and Volker points to very relevant section of the readme file.&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:14:17 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824123#M4854966</guid>
      <dc:creator>regdomaratzki</dc:creator>
      <dc:date>2013-09-16T10:14:17Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824125#M4854968</link>
      <description>&lt;P&gt;Yes, we don't use the "ß", but then, we have éèà and ç for our french customers as well... &lt;span class="lia-unicode-emoji" title=":slightly_smiling_face:"&gt;🙂&lt;/span&gt;&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:17:53 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824125#M4854968</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2013-09-16T10:17:53Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824126#M4854969</link>
      <description>&lt;P&gt;Thanks, this solved the problem.
I assume a "CharSet=windows-1252" would also work?&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:20:37 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824126#M4854969</guid>
      <dc:creator>Former Member</dc:creator>
      <dc:date>2013-09-16T10:20:37Z</dc:date>
    </item>
    <item>
      <title>Re: dbremote on windows + linux (Character encoding problem)</title>
      <link>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824127#M4854970</link>
      <description>&lt;P&gt;Assuming that is the proper character set, yes.  If all the database use the same encoding, I prefer using charset=none everywhere to tell dbremote never to do characeter set translation, and this solution will work on every computer, regardless of the locale specified on the computer.&lt;/P&gt;</description>
      <pubDate>Mon, 16 Sep 2013 10:33:49 GMT</pubDate>
      <guid>https://community.sap.com/t5/technology-q-a/dbremote-on-windows-linux-character-encoding-problem/qaa-p/13824127#M4854970</guid>
      <dc:creator>regdomaratzki</dc:creator>
      <dc:date>2013-09-16T10:33:49Z</dc:date>
    </item>
  </channel>
</rss>

