hex values in result

I'm aware of this bug-report:
http://code.google.com/p/heidisql/issues/detail?id=725
And the fact that you guys don't consider this a bug.

What i don't understand is why heidi can't detect what character set the server is using and set it as the client character set. When i connect to mysql with for example PHP, it also has no problem at all, to output the results in a human readable way instead of hex values. Same goes for the mysql console.

For all of you who have problems and think using CONVERT() is a hassle (which it is), try: SET NAMES latin1 (or whatever character you db is using: you can look this up in the Host tab)

The only thing i haven't been able to default correctly is the output of functcions like md5() .. if anyone has a suggest, that would be welcome.

What i don't understand is why heidi can't detect what character set the server is using and set it as the client character set. When i connect to mysql with for example PHP, it also has no problem at all, to output the results in a human readable way instead of hex values. Same goes for the mysql console.

Well, that's because there's no practical way to do that. Different server functions output different character sets, depending on the particular bug.

In the problem mentioned in issue 725, the bug is in DATE_FORMAT. To figure out what character set the server is using but not telling us about, we'd have to download the source code to the server and manually walk the code path that DATE_FORMAT takes, find out where the character set used is coming from, and patch HeidiSQL to look up that same information.

Then we'd have to parse all SQL statements, look for DATE_FORMAT, and apply the knowledge gained above.

Another twist is that there is multiple character set related DATE_FORMAT bugs. Meaning that for different server versions, different information has to be sought, and different workarounds has to be used.

There are other similar bugs, where the character set information cannot be retrieved via SQL to the MySQLd process, but you actually have to access the filesystem of the server, which is even harder.

So, long story short, you're insane. (Well, the suggestion is, but you get my point.)

It "works" in PHP only as far as you happen to be using the same character set on your client as on the server. PHP is buggy in that it will silently corrupt your data if you're not. Same goes for the MySQL CLI client.

So yeah, basically a choice had to be made: do what PHP/mysqlcli does, work most of the time, but risk silently corrupting user data -versus- make users actually notice that there is a bug in their server, enabling them to either upgrade the server or manually workaround the bug with SQL. The choice was made to not risk anything, and alert the user that there is a problem. Sorry.