Hi Stefan,

<<There's a wrong assumption right at the beginning:
<<"Since version 4.0 MySQL uses utf8 to store data internally."
<<This is not true. What's true is this:
<<"mysqldump from MySQL 4.1.2 or later uses utf8, and earlier versions use latin1."

Yes, there you got me. This information is wrong and I corrected my article on my homepage. Here I can't do this because I didn't post it here. Thank you for your correction.

<<There are more wrong assumptions in this article, and generally I find it more confusing than helpful.

Well, I wrote this article 2 years ago. At this time there was nearly no useful information about this topic available. I tried to point out that scipts now have to "talk to MySQL" in a different way and need to specify the charset they expect by sending "SET NAMES", right after the connection is made. Many, many programms didn't and still don't do this and therefor don't get the control about what encoding is delivered by MySQL and don't know which strings are placed on the html site. In many boards there are heaps of cries for help because so many users do have problems with their board or shop when they move from one host to another.

I tried to describe what is the reason for that and what one can do to get things sorted. From the very postive feedback I got, I don't think that my article is confusing.

 <<The mysqldump client program takes into consideration a whole bunch of character set-related settings

In theory yes, but in practise there were a lot of situations where even mysqldump itself was not able to restore its own backups - sometimes even on the same server where the backup was made - because e.x. vars like @SQL-MODE are set to null. I don't want to get here in detail because actually I don't have an case with which I could proof this. But I can tell you, that I had heaps of help calls where this was the case. I often could fix this by deleting the condition-lines like /*40101 SET .. */.

About the documentation:
I was looking for the information where I could find a listing what charset was added in version 4.0 and what encoding was removed in version 4.1. E.x. in version 4.0 there is a charset called "german1". I can't find this charset in version 4.1. So MySQl 4.1. is not backwards compatible to version 4.0. Try to restore a backup encoded in german1 on a MySQL server of version 4.1  and you will know what I mean. :)

<<By the way, looking at that page will make you aware that there is in fact documentation available for MySQL 4.0, and even 3.23, while the article says there isn't.

The documentation now mixes all these versions together. When reading it you often don't know for which version the documentation is valid.

Or try the german link for the documentation of "set names": http://dev.mysql.com/doc/refman/5.1/de/
Although there is a link on this page for the "MySQL 4.0 Reference Manual" the link also points to the 5.1-site. My conclusion was that these version are no more supported. Now I see, that the english documenation is much more detailed. But still version 3.23, 4.0 and 4.1 are mixed. There are so many differences between version 4.0. and 4.1 from the view of a programmer, that this kind of documentaion is not sufficient.

Nevertheless: don't get me wrong! I love MySQL and its possibilities and I do my very best to help others to understand how to do working backups on shared hostings without having access to mysqldump.

But my conclusion still is: I want to do everything I can do, to make people update their MySQL verion 4.0 server to at least version 4.1 or greater.

Maybe this is the wrong place to discuss this. I invite you to come to the english section of my support board of MySQLDumper to continue this technical talk (I like :) ). http://forum.mysqldumper.de/index.php?c=6

Best regrads from Germany,
Daniel Schlichtholz (DSB)