on 2013 Sep 16 10:50 AM
Hello,
we use SQL Anywhere 10.0.1.4103.
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.
When a windows remote enter text in the database, sometimes the replication fails on the linux systems with this message:
I. 2013-09-03 09:03:00. INSERT INTO DBA.CardEntries(CardEntries,ClientCard,CreationDate,Amount, REMOTENAME,Salesperson,EntryProcessed,BatchID) VALUES ('O000CB','J001UW','12:26:15.446918 2013/08/30',169,'SiteTest1','Sil Sch.r',0,NULL) E. 2013-09-03 09:03:00. SQL-Anweisung fehlgeschlagen: (-131) Syntaxfehler bei 'Sil Sch.,0,NULL)' in Zeile 3 E. 2013-09-03 09:03:00. Wird übersprungen: E. 2013-09-03 09:03:00. INSERT INTO DBA.CardEntries(CardEntries,ClientCard,CreationDate,Amount, REMOTENAME,Salesperson,EntryProcessed,BatchID) VALUES ('O000CB','J001UW','12:26:15.446918 2013/08/30',169,'SiteTest1','Sil Sch.r',0,NULL)
The "offending" text is the entry for the sales person which should be "Sil Schär", but apparently it stumbles over the ä character.
All databases have the same encodings:
CHAR Collation: 1251LATIN1
CHAR Encoding: windows-1252
NCHAR Collation: UCA
NCHAR Encoding: UTF-8
The replication is done via Email. In the connection string of dbremote we specify nothing special, only uid,pwd,eng,dbn
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.
Strange is, that messages with the ü character are correctly replicated, but the ä seems to cause problems....
Any ideas how to solve it ?
Request clarification before answering.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
| User | Count |
|---|---|
| 13 | |
| 8 | |
| 6 | |
| 4 | |
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.