From: Marcus Bointon Date: November 15 2007 9:16am Subject: Re: Replication breaks with error 1406 when confronted with Umlauts List-Archive: http://lists.mysql.com/replication/995 Message-Id: MIME-Version: 1.0 (Apple Message framework v912) Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On 15 Nov 2007, at 00:13, Christoph Lechner wrote: > BTW: Why does he say "G=C3=C2=BCltig"? It should be G=FCltig, so the = Umlaut =FC > got scrambled. > > All the rows already in the table don't contain any Umlaut (the =20 > Umlauts > are encoded in ü etc. HTML style), so the first Umlaut that =20 > wasn't > encoded broke the setup. (Needless to stress that the setup _should_ > survive umlauts ...) To me it looks like that char is UTF-8 encoded, when everything you =20 mention is ISO. Either way, collations and charsets are binary safe in =20= MySQL anyway, it's just down to your terminal etc to interpret it =20 correctly. In this case I can see you having done something like =20 submitting a UTF-8 string to a field that's expecting ISO, and your =20 terminal is displaying ISO, so you're seeing corruption, though it may =20= actually be OK in the db. As for why it didn't get converted to an HTML entity, I'd guess that =20 htmlentities() (you using PHP?) is on the lookout for an ISO =FC, and =20= the UTF-8 one slipped by unnoticed. So I'd suspect that there's a =20 browser somewhere that didn't obey either your content-type HTTP =20 header or meta tag specifying an ISO charset. Having said all that, I don't know why this should have any bearing on =20= the replication problem. Any help? Marcus --=20 Marcus Bointon Synchromedia Limited: Creators of http://www.smartmessages.net/ UK resellers of info@hand CRM solutions marcus@stripped | http://www.synchromedia.co.uk/