Bug – Character for ü, ö, ä…

[the_wizzkid]

Im using the german collation for mysql DB, and using Umlaute- ä,ö.ü. In the older SQLyog version 4.01, I got these shown on my result window. Now, with the SQLyog v4.06 RC1, I get weird characters instead…

These weirdo characters are copied, too when using table-copy… help!

[peterlaursen]

I have a base with a lot of strings with german, swedish, spanish, portuguese, french, czech etc. that all contain special characters and no problems with Sqlyog and either MySQL 4.0.x, 4.1.x or 5.0.x .

However I notice that when Ritesh (he has a copy of some of the data) queries this base of mine he gets weird graphics too

Ritesh has said that all chracter set related issues wil be fixed with Sqlyog 4.1.

What is your MySQL server version? And you haven't changed it recently ?

Could you paste in the definition for the table with just a few rows of data taht mismatch ?

(or better append it as a file – or both!))

I have experienced that M$-Excel-2000 is not compatible with the management of character sets of MySQL 5.0.x (and maybe 4.1.x too). Excel destroys the charcter set although data display correctly in the program itself. So if your data have been imported with Excel or another program with similar defect that could be the problem!

[the_wizzkid]

Thank you peterlaursen,

I'm running 4.19 My sql Server.

Haven't changed anything on the server, only changed Sql yog.

The data in the Database is with Ü,ß etc. and I can see them correctly using my ERP system.

The Import has nothing to do with it, as I still have the correct data in the Database:

here is the output from Sqlyog:

00 01 D 010008 D Hübner-Kuhlmann

00 01 D 010009 D Unverwerth

00 01 D 010010 D Rummel

00 01 D 010012 D Scholtz

00 01 D 010013 D Außerer

00 01 D 010014 D Röhling/Richter/Schnitzer

with the earlier Version of Sql Yog – 4.01, the output is correct. ( I just tried it from another computer)

here is the output from our ERP system:

01 D 010008 1200 false AKTV EUR true Hübner-Kuhlmann

01 D 010009 1200 false AKTV EUR true Unverwerth

01 D 010010 1200 false AKTV EUR true Rummel

01 D 010012 1200 false AKTV EUR true Scholtz

01 D 010013 1200 false AKTV EUR true Außerer

01 D 010014 1200 false AKTV EUR true Röhling/Richter/Schnitzer

after doing a table copy, I see these caracters in the ERP system, too…

so they aer gettig altered during the copy. (I get the same effect if I do a mysqldump without the parameters: –default-character-set = latin1

Somthing changed with the characterset between SQLyog versions 4.01 and the newest one…

[Shadow]

This may be a character encoding issue: SQLyog's connection charset may differ from that of strored data. Issue a “SET NAMES charset_name” command from SQL window and query your database afterwards. Hope, you'll see the special german characters show up normally!

[the_wizzkid]

Great, Shadow!

this resolved the problem, also the copying is fine now.

I'm just wondering- why does it function with a new installation of sqlyog 4.0.1 and when I update to the v4.06 RC1, it's gone? is there a kind of reset.. hmmm..

Thanks to both for your help.

[peterlaursen]

When I open Sqlyog the first SQL-statement from the history pane is

“Set character_set_results=utf8”

even though my default charcater set is latin1 with swedish collation (never bother to change to dansih though I'm Danish, since everething works!) . However still everything is displayed correctly on my screen. But I think the german collation is something rather new (I remember I read in the MySQL documentation/changelogs that they introduced it to produce the same sort order as in German phone-books). So that collation might still have it's problems.

Quite funny actually since Swedish also have special characters with umlauts ä and ö (but no ü).

[Shadow]

The funny thin is that Hungarian alphabet also contains special characters (ö, ü – like German), however, I use latin1 with Swedish collation just as Peterlaursen does and I have no problem with that. But other developers do suffer a lot with encoding issues… The real problem is that you may set different encodings for you db, db connection, queries, os, HTML page, so I can't really tell which one goes wrong when a character is not displayed correctly!

[Author]

Posts