MySQLDumper-Board Forum Index Follow me on Twitter

Portal  •   Forum  •  Downloads  •  Profile  •  Search   •  Register  •  Log in to check your private messages  •  Log in  •  


 Die Umlautproblematik - was, wieso, was tun?

Post new topicReply to topic
Author Message
DSB
Developer
Developer




Age: 45
Joined: 30 Apr 2004
Posts: 17254
Location: Herdecke


germany.gif

PostPosted: 2007-02-04, 00:14    Die Umlautproblematik - was, wieso, was tun? Reply with quoteBack to top

An English translation of this article can be found here: http://www.howtoforge.com/the-umlaut-problem-how-to-successfully-back-up-and-restore-mysql-databases-with-special-characters-using-mysqldumper

Edit 01.08.2009: Im Internet magazin sind 2 Artikel von mir zu dieser Problematik erschienen, welche nun auch öffentlich aufrufbar sind. Zur weiterführenden Info:
Workshop gegen das Chaos
Buchstabensalat


Die Umlautproblematik:

In zahlreichen Foren häufen sich die Meldungen zu falsch dargestellten Umlauten nach einem Serverumzug.
Es wird zwar von vielen Seiten versucht zu helfen, aber den richtigen und vollständigen Durchblick scheint kaum jemand zu haben.
Sogar die Support-Hotlines von Hostern stoßen hier an ihre Grenzen.
Man findet unglaublich viele Halbwahrheiten, die in bestimmten Situationen zwar richtig sind, aber dem Betroffenen dann meistens doch nicht helfen können, da seine Arbeitsumgebung anders konfiguriert ist.

Naturgemäß habe ich mich als Entwickler von MySQLDumper lange mit den unterschiedlichsten Aspekten dieser Problematik beschäftigt und glaube nun hier einen Komplettüberblick geben zu können, der alle Aspekte berücksichtigt.
Dabei steckt sehr, sehr viel Forschungsarbeit in den hier aufgeführten Erklärungen.

Aber sei vorgewarnt: der Zusammenhang ist nicht einfach und ist auch nicht in 2 Minuten erklärt!

Es hat schon seinen Grund warum sich die Hilfeschreie in vielen Foren häufen und kaum geholfen werden kann.
Wer eine einfache Erklärung sucht (wo muss ich klicken damit es funktioniert?), braucht gar nicht weiter zu lesen (sondern soll das Backup einfach mit MySQLDumper ab Version 1.22 machen und damit auch wieder einspielen - dann ist alles in Ordnung *lach*).
Dieser Artikel ist lang und erfordert Aufnahmebereitschaft - dafür hast Du danach den benötigten Durchblick. Wink

Es ist bisher unglaublich schwer zu diesem Thema fundiertes Wissen zu finden und dementsprechend lange hat es auch gedauert, bis ich selbst den Zusammenhang verstanden habe.
Diese Odyssee will ich Dir ersparen. Wer sich selbst bereits intensiver mit diesem Thema auseinandergesetzt hat, weiß was ich meine. Wink

Trotzdem habe ich die Weisheit natürlich nicht mit Löffeln gefressen - die hier geschilderten Aspekte beruhen auf den Erfahrungen, die ich größtenteils auch über die Einsichten durch Installationen von MySQLDumper-Usern auf den unterschiedlichsten Servern gewonnen habe (vielen Dank an alle, die mir ihr Vertrauen schenkten):
solltest Du einen Aspekt kennen, den ich hier nicht berücksichtigt habe oder falsch darstelle, so bitte ich um Nachricht.

Die Theorie - warum kommt es überhaupt zu Umlautproblemen?

Einfach ausgedrückt: das liegt an unterschiedlichen MySQL-Server-Versionen mit unterschiedlich eingestellten Standard-Zeichensätzen.

Wenn ein Script (egal welches) Daten zum MySQL-Server geschickt oder abgeholt hat, dann waren die Daten früher (zumindest in Deutschland) grundsätzlich in latin1 kodiert.
Ein Datenbank-Backup-Programm (wie z.B. MySQLDumper) nimmt die Daten entgegen und speichert diese als SQL-Befehl in einer Textdatei.
So weit, so gut.
Aber: eine auf einem Server per Script geschriebene Textdatei enthält keine programmtechnisch auswertbare Kodierung!

Das bedeutet, dass ein Script nicht wissen kann, in welcher Kodierung Zeichenketten darin abgelegt sind.
Heutzutage gibt es die unterschiedlichsten Kodierungen (Zeichensätze) und so sehen die gleichen Daten je nach übermittelter Kodierung eben anders aus, obwohl die Ursprungsdaten gleich sind.

Texteditoren können utf8-kodierte Textdateien als solche markieren, indem sie eine spezielle Kennung an den Anfang der Datei schreiben - das sogenannten BOM-Kennzeichen (Byte-order-Mark). (siehe http://de.wikipedia.org/wiki/Byte_Order_Mark und offizielle Unicode-Erklärung http://unicode.org/unicode/faq/utf_bom.html#22 )
Mit dieser Kennung kann aber ein Webserver bzw. der PHP-Interpreter nichts anfangen und liefert die Zeichen unverändert an den Webbrowser aus - was natürlich nicht gewollt ist. Also fällt diese Art der Kennzeichnung von Dateien im Webbereich aus und es wird eine Textdatei ohne Kennung geschrieben. Damit ist also unbekannt in welcher Zeichensatzkodierung die Textdatei geschrieben wurde.
Und genau darauf beruht das ganze Übel der Umlautproblematik.

MySQL Version 3.x speicherte und lieferte die Daten in latin1 (weil das zumindest in Deutschland bei der Installation fest eingestellt wurde).
Hier war auch nichts für den User oder ein Script einstellbar - es kam immer latin1 raus.
Ein Backupfile von einem MySQL-Server Version 3.x enthält also latin1-kodierte Daten und der MySQL-Server erwartetet ebenso latin1-kodierte Daten beim Wiedereinspielen.
Beim Wiederherstellungsprozess einer Backupdatei liest MySQLDumper zeilenweise die Datei aus, erkennt Anfang und Ende eines MySQL-Befehls, extrahiert ihn und sendet ihn unverändert an den MySQL-Server.
In jetzigem Szenario passt also alles zusammen.
Backupdatei ist latin1 und MySQL erwartet latin1 -> passt!
Hier gibt es keine Umlautprobleme.


Wenn doch alles so wunderbar funktionierte, warum hat man angefangen da etwas zu ändern?

Es gibt jede Menge landesspezifischer Zeichen, die sich nicht alle in einem (1-Byte-kodiertem) Zeichensatz darstellen lassen.
Unsere Umlaute ÄÖÜ finden sich z.B. nicht in anderen Zeichensätzen, so dass z.B. ein User aus Japan Probleme mit der Darstellung einer deutschen Webseite hat und u.U. Zeichen falsch dargestellt bekommt.
Dies führt zu einer Menge von programmtechnischen Problemen - man denke nur an Programme, die mehrsprachig sind (z.B. der MySQLDumper) oder auch mehrsprachige Webseiten. Jede Sprachvariante der Webseite müsste alle Textausgaben im jeweils landesspezifischen Zeichensatz ausgeben. Unterschiedliche Header müssen gesendet werden, damit der Brower überhaupt weiß, welche Sprache er darstellen muss und zusätzlich muss der Browser auch den Zeichensatz installiert haben. Die damit verbundene Problemliste ist lang und stellt Programmierer vor viele, nicht einfach zu lösende Aufgaben.

Es besteht also der Wunsch, möglichst alle Zeichen aller Sprachen mit einem einzigen Zeichensatz darstellen zu können, um genau diese Probleme zu vermeiden.
Deshalb wurde der Zeichensatz Unicode entwickelt: http://de.wikipedia.org/wiki/Unicode
Damit man aber die immense Menge aller darstellbaren Zeichen in einem einzigen Zeichensatz eindeutig abbilden kann, benötigt man natürlich mehr Speicherplatz. Um dem erhöhten Speichervolumen Rechnung zu tragen wurden daraufhin verschiedene Speicherungs- und Darstellungsformate entwickelt.
Das bekannteste ist UTF8 ( http://de.wikipedia.org/wiki/UTF-8) .
UTF steht für "Unicode Transformation Format" (Unicode Umwandlungsformat) und ist in der Lage, das benötigte Speichervolumen zu reduzieren, indem nur bestimmte Zeichen mehrere Bytes benötigen. Viele der häufigen Standardzeichen benötigen weiterhin nur 1 Byte.

Jetzt kommen wir zum praktischen Teil:
Seit MySQL 4.0 benutzt MySQL intern zum Speichern von Daten utf8.
Edit DSB: Das ist nicht ganz richtig. In diesem Kommentar wird korrekterweise darauf hingewiesen, dass das erst seit Version 4.1.2 der Fall ist!

Das bedeutet aber nicht, dass Programmierer jetzt zwangsläufig alle Programme auch utf8-kodieren müssen, denn MySQL kann die Daten in jedem gewünschten Zeichensatz liefern. Wir müssen dem Server nur sagen, in welchem Format wir die Daten bekommen möchten und auch in welchem Format wir Daten liefern!

Dazu können Programme nach dem Verbindungsaufbau z.B. den Befehl "SET NAMES latin1" an den MySQL-Server senden.
Dadurch "einigen" sich das Programm und der MySQL-Server darauf, dass der Datenaustausch zwischen beiden über latin1-kodierte Daten geschieht. Werden Daten von einem Programm an den MySQL-Server gesendet, nimmt MySQL die latin1-Daten entgegen, wandelt sie intern in utf8 und speichert sie korrekt.
Fragt das Script Daten ab, dann liest MySQL die Daten aus und wandelt sie vor der Rückgabe an das Script wieder in latin1 um.
Die Kommunikation klappt also perfekt, wenn sich die beiden auf einen Zeichensatz einigen, da sie so wortwörtlich die gleiche Sprache sprechen.

Wenn das Programm, welches sich mit dem MySQL-Server verbindet, dem Server nicht mittteilt welcher Zeichensatz verwendet werden soll, dann greift die Standardeinstellung des MySQL-Servers (die Daten werden dann in der Kodierung geliefert, die in der MySQL-Systemvariablen character_set_connection voreingestellt ist).
Und genau hier knallt es in der Praxis wenn die Daten in einer anderen Kodierung geliefert werden, als das Programm erwartet.
Das gilt für beide Richtungen.
Geht das Programm davon aus, dass es latin1-kodierte Daten bekommt und der Server hat standardmäßig utf8 als Verbindungskodierung eingestellt, dann passt es natürlich nicht. Das gleiche gilt, wenn das Script Daten an den MySQL-Server liefert.

Die meisten Scripte tragen dem Umstand, dass die Kodierung der Verbindung angegeben werden muss (noch) nicht Rechnung (MySQLDumper tut dies bis einschließlich Version 1.21b6 auch nicht).
Hier kommt es jetzt zu ungewollten Effekten, denn der Standardzeichensatz ist bei einem Server auf latin1 gestellt, auf einem anderen auf utf8 und wieder bei einem anderen auf etwas ganz anderes.
Schauen wir uns das in der Praxis mit MySQLDumper Version 1.21b6 an:

Szenario 1:
- Umzug von MySQL 3.x auf 4.x, wobei der neue 4er Server als Standardzeichensatz latin1 eingestellt hat.
- Backup von Version 3.x liegt also latin1-kodiert vor
- bei der Wiederherstellung werden vom Dumper 1.21 (unwissentlich) latin1-kodierte Zeichen an den MySQL-Server übermittelt
- MySQL nimmt die Zeichen entgegen und wertet diese als latin1, da nichts anderes vereinbart wurde, wandelt diese intern in utf8 und speichert sie korrekt, da die Standardeinstellung zufällig mit der Kodierung der Datei übereinstimmt
- Alles OK. Umlaute passen.


Szenario 2:
- Umzug von MySQL 3.x auf 4.x, wobei der neue 4er Server als Standardzeichensatz utf8 eingestellt hat.
- Backup von Version 3.x liegt also wieder latin1-kodiert vor
- bei der Wiederherstellung werden vom Dumper 1.21 (unwissentlich) latin1-kodierte Zeichen an den MySQL-Server übermittelt
- MySQL nimmt die Zeichen entgegen und denkt "Ey cool, es ist nichts anderes vereinbart, also bekomme ich utf8-kodierte Strings. Die brauche ich ja gar nicht umwandeln und kann sie so in der Datenbank ablegen."
- jetzt speichert MySQL latin1-kodierte Zeichen als utf8 ab!
- da die Umlaute in latin1 ohne korrekte Umwandlung keine Entsprechung in utf8 besitzen, werden diese beim Auslesen als Fragezeichen dargestellt
- Hier knallt es also! Die Umlaute werden bei der Anzeige als Fragezeichen oder Rechtecke dargestellt.


Szenario 3:
- Umzug von MySQL >=4.1 auf >=4.1, wobei der alte Server den Standardzeichensatz utf8 und der neue Server als Standardzeichensatz latin1 eingestellt hat
- das Backup vom Quellserver liegt also utf8-kodiert vor, da beim Auslesen nichts anderes vereinbart wurde und der Server utf8 geliefert hat
- bei der Wiederherstellung werden vom Dumper 1.21 (unwissentlich) utf8-kodierte Zeichen an den neuen MySQL-Server übermittelt
- MySQL nimmt die Zeichen entgegen und speichert die utf8-Daten als latin1 ab
- da utf8 für Sonderzeichen mehrere Bytes Speicherplatz benötigt und diese aber nun als einzelne Buchstaben in latin1 gewertet werden, werden aus einem Sonderzeichen 2 (oder mehr) Buchstaben bei der Ausgabe
- Beim Wiederauslesen und der Anzeige auf der Webseite sehen Umlaute dann z.B. so aus: äöü (das entspricht äöü). Das Ä ist eigentlich der Code, der einige der Sonderzeichen in utf8 einleitet, wird hier aber nicht so interpretiert, da der MySQL-Server ja von latin1-kodierten Daten ausgeht. Und schon kracht es wieder...

(Edit: für diesen Fall habe ich ein Korrekturprogramm entwickelt. Siehe http://forum.mysqldumper.de/viewtopic.php?p=19187#19187 )

Praxishilfe:
Dem aufmerksamen Leser wird nun aufgefallen sein, dass die Wiederherstellung nur dann korrekt funktioniert wenn das Backup in der Kodierung vorliegt, die der neue Server erwartet. Aber woher weiß man, was der Standardzeichensatz eines MySQL-Servers ist?

Dazu gibt uns MySQLDumper glücklicherweise umfassend Auskunft!
Unter Home/MySQL-Variablen/Variablen finden wir eine ganze Reihe von MySQL-Einstellungen:

z.B.:
Image

Davon interessieren uns vor allem die Einträge zu character_set_client und character_set_connection, die in der Regel gleich sind.
Hier steht in welchem Zeichensatz Daten vom Client erwartet und geliefert werden, wenn nichts anderes vereinbart wird (der "Client" ist in dem Falle sinngemäß das Programm/Script, welches die Verbindung zum MySQL-Server aufbaut).

Die anderen Werte können wir getrost vernachlässigen - egal, was da steht.
MySQL wandelt alle Daten aufgrund der Verbindungskennung in den entsprechenden Zeichensatz um wenn dies nötig ist.
Uns kann völlig egal sein, welchen Standardzeichensatz die Datenbank hat oder wie MySQL intern (character_set_system) Daten abspeichert. MySQL orientiert sich bei der Annahme und Ausgabe von Daten an der Kodierung der Verbindungskennung und wandelt alles selbstständig intern. Hier brauchen wir uns überhaupt gar keine Gedanken machen: wenn die Verbindungskennung auf utf8 steht, dann bekommen wir auch utf8-kodierte Daten und müssen ebenso utf8-kodierte Daten senden.
Punkt - Ende - aus. Wink

Um an dieser Stelle direkt mit einem weiteren, weit verbreiteten Irrglauben aufzuräumen:
die Collation (Kollation=Sortierreihenfolge) wirkt sich in keinster Weise beim Einspielen von Daten aus.
Lediglich beim Auslesen der Datenbank durch Queries mit "ORDER BY"-Klausel wird so festgelegt, nach welchen Kriterien sortiert werden soll. Siehe offizielle MySQL-Dokumentation: http://dev.mysql.com/doc/refman/5.1/de/charset-we-sets.html

Das war zu theoretisch?
Ok, hier ein Beispiel:
Gehen wir davon aus, dass wir 3 Datensätze in einer Tabelle haben:
ID Name
1 Zappa, Frank
2 Zäppel, Ernst
3 Zander, Bernd

und uns die Liste der Datensätze mittels 'SELECT * FROM `tabelle` ORDER BY `Name`' zurückgeben lassen.

Rückgabe bei Sortierung (Collation) latin1_german1_ci (Wörterbuchsortierung - Umlaute werden alphabetisch einsortiert):
3 Zander, Bernd
1 Zappa, Frank
2 Zäppel, Ernst

Rückgabe bei Sortierung (Collation) latin1_german2_ci (Telefonbuchsortierung - Umlaute stehen oben):
2 Zäppel, Ernst
3 Zander, Bernd
1 Zappa, Frank

Du siehst, dass sich die Daten über die Collation (Sortierreihenfolge) nach verschiedenen landesspezifischen Sortierkriterien sortieren lassen.
Das hat aber überhaupt gar nichts mit der Zeichensatz- und damit der Umlautproblematik zu tun. Wenn Du in einem Forum also liest, dass man die Collation bei Umlautproblemen ändern sollte, dann kannst Du den Hinweis getrost überlesen. Wink
Das ist alleinige Sache der eingesetzten Software und braucht Dich nicht zu kümmern.
Aber das nur am Rande...
-------------------------

Was mache ich jetzt, wenn ich über die Anzeige im MySQLDumper feststelle, dass sich die Standardzeichensätze von altem und neuen Server unterscheiden?
Einen entscheidenen Vorteil hast Du nun bereits: Du weißt, welche Kodierung vom neuen MySQL-Server erwartet wird!
Also brauchst Du letztlich nichts weiter zu tun, als ihm genau diese Kodierung zu liefern.
Dazu benötigst Du einen TextEditor, der in der Lage ist eine Text-Datei in verschiedenen Formaten zu speichern (Achtung, aber ohne BOM - siehe oben!).
Mein Lieblingseditor zu diesem Zweck ist TextPad: http://www.textpad.com/download/index.html
Noch umfangreichere Möglichkeiten mit vielen weiteren Zeichensätzen bietet der ebenfalls sehr gute und zudem noch kostenlose SuperEdi: http://www.pcfreunde.de/download/detail-5727/superedi.html

Was ist also zu tun?
Lade das Backup herunter. Wenn das Backup im GZ-Format vorliegt (Dateiendung *.sql.gz), so entpacke es und achte darauf, dass der Entpacker diese Datei auch korrekt entpacken kann. Mit alten Versionen von z.B. WinRar gab es hier Probleme!

Öffne die Datei nun mit Deinem Texteditor und wähle anschließend "Datei/Speichern unter". Im unteren Bereich findest Du die Möglichkeit den Zeichensatz zu wählen den Dein Server erwartet. Dabei entspricht "Standard" latin1.

Die so gespeicherte Datei kannst Du mit z.B. WinAce wieder in das GZ-Format packen, auf den Server laden und mit MySQLDumper einspielen.
Das wars schon.

--------------------------

Was machen wir nun, um MySQLDumper hinsichtlich dieser Aspekte zu verbessern?

Nun, ich habe mir lange den Kopf zu diesem Umstand zerbrochen.
In einem anderen Datenbank-Verwaltungsprogramm muss der User die Kodierung der Datei händisch wählen.
Diese Lösung kommt für mich aber nicht in Frage, da der User in 99% aller Fälle überhaupt nicht weiß, was er wählen muss und wie sich das auswirkt (Vielleicht weiß er es jetzt, nach dem Studium dieses Artikels. *g*)

MySQLDumper ist bisher für eine einfache und sichere Bedienung bekannt und das soll auch so bleiben.

In Version 1.21b12 startete ich den Versuch die Verbindung standardmäßig auf utf8 zu stellen.
Das klappt bei MySQL-Servern ab Version 4.1 aufwärts wenn das Backup auch mit MySQLDumper gemacht wurde.
Kommt das Backup allerdings von einem anderen Programm und das Backup ist nicht im utf8-Format gespeichert, so klappt das aus oben erklärten Gründen nicht.

Version 1.21b13 überlässt es dem User die Verbindungskennung explizit auf utf8 zu setzen, aber auch hier hängt es davon ab welcher Standardzeichensatz beim MySQL-Server eingestellt ist und in welcher Kodierung das Backup vorliegt. Wenn der Standardzeichensatz sowieso schon utf8 ist, dann ist es völlig egal, ob der Haken gesetzt ist oder nicht.

Hier bietet MySQLDumper bisher also noch keine perfekte, immer funktionierende Lösung, was wir natürlich ändern wollen. (Mit Version 1.22 weitestgehend erledigt)

Aufgrund der hier beschriebenen Erkenntnisse strebe ich folgende Lösung an:
- MySQLDumper muss also (genauso wie Du) wissen, in welcher Zeichensatz-Kodierung das Backup gespeichert wurde. Nur so kann er bei der Wiederherstellung überprüfen, ob die Kodierung des Backups zu der Kodierung des MySQL-Servers passt und kann gegebenenfalls die Verbindung auf den richtigen Zeichensatz "eichen". (Mit Version 1.22 erledigt)

- MySQLDumper schreibt dazu demnächst die Kodierung beim Erstellen eines Backups als Kommentar mit in das Backup hinein (Mit Version 1.22 erledigt)

- beim Wiedereinspielen wird die Kodierung wieder ausgelesen und mit der aktuellen Verbindungskennung des MySQL-Server verglichen (Wiederhole ich mich? Mit Version 1.22 erledigt)

- bei Abweichungen besteht ab MySQL 4.1 die Möglichkeit der Anpassung, so dass MySQLDumper dem Server mitteilen kann in welcher Kodierung er Daten liefert (Jup, das macht MySQLDumper ab Version 1.22. Wink )

- bei Versionen vor 4.1 ist das nicht möglich und so ist hier der User gefragt das Backup in der richtigen Kodierung zu speichern. Abgesehen davon rate ich jedem auch aus anderen Gründen dringend auf mindestens MySQL Version 4.1 zu aktualisieren. Alles vor 4.1 ist zu alt und jeder Hoster bietet einem auf Anfrage die Möglichkeit in irgendeiner Form den Server zu wechseln. (Falls nicht solltest Du wechseln - und zwar den Hoster Wink )

- das gilt auch für Backups anderer Programme - da hier keine Information über die Kodierung vorliegt, muss der User diese zwangsläufig angeben
(Mit Version 1.22 erledigt - bei Backups von anderen Programmen kannst Du wählen, wie die Backupdatei interpretiert werden soll!)

- es gibt zwar PHP-Module (z.B. mbstring), die in der Lage wären eine automatische Erkennung von Kodierungen durchzuführen, aber erstens funktionieren auch diese nicht wirklich zuverlässig und zweitens passt es nicht in das Konzept von MySQLDumper bestimmte Module auf dem Server vorrauszusetzen. Diese Lösung fällt also raus.

So bliebe der Dumper innerhalb seiner eigenen Anwendung weitestgehend automatisiert (der User muss keine Angaben zur Kodierung machen - der Dumper weiß schon was zu tun ist) und wäre trotzdem flexibel mit Fremdbackups einsetzbar.
(Ja, ist er ab 1.22 - definitiv! Wink )

Ich hoffe, das ist im Sinne der Anwender.
In meinem nächsten Urlaub werde ich mich dieser Problematik widmen und MySQLDumper um diese Funktionen erweitern.
(Oh ja, das habe ich getan. Fast meinen kompletten Urlaub habe ich in die Weiterentwicklung des Dumpers gesteckt. Nicht nur die Umlautproblematik ist gelöst. Version 1.23 mit weiteren Features kommt bald! Und alles stelle ich kostenlos zur Verfügung, damit Du keine Probleme hast. Ich bin bekloppt, aber ich bin es gerne. Mr. Green )

-----------------------------------------

Ein vorletztes Wort:

Ich habe die MySQL-Version 4.0.x hier bisher unter den Tisch fallen lassen.
In dieser Version wurden unterschiedliche Zeichensätze eingeführt, allerdings noch sehr experimentell. Mit Version 4.1.2 kamen neue Zeichensätze hinzu und einige aus Version 4.0 verschwanden wieder.
Ich habe unglaublich viele Probleme mit MySQL 4.0.x-Servern gehabt. Sie verhielten sich teilweise nicht so, wie im offiziellen Manual beschreiben und haben mir einige graue Haare beigebracht.
Auf der offiziellen Seite heißt es ( http://downloads.mysql.com/archives.php?p=mysql-4.0 ):
Quote:
Because version 4.0.* of MySQL Server are in such low demand we have decided to stop hosting binaries of these older versions.
und man findet auch keine Informationen mehr zu diesen Versionen.
Zu deutsch: "Aufgrund der geringen Nachfrage haben wir uns dazu entschlossen, die Downloadmöglichkeit dieser alten Version einzustellen".
Ich glaube allerdings, dass diese Version einfach noch zu buggy war und die dadurch bekannt gewordenen Probleme eben seit Version 4.1 behoben sind. MySQL bietet diese Version also ganz bewußt nicht mehr zum Download an, weil es eben viele Probleme in Bezug auf Zeichensätze damit gab.

Solltest Du also auf einem Server sein, der noch MySQL 4.0.x einsetzt, dann tritt Deinem Hoster so lange auf die Füße, bis er die MySQL-Version auf mindestens 4.1 aktualisiert hat.
Version 4.0.x bringt jede Menge Probleme mit sich, die sich teilweise programmtechnisch einfach nicht lösen lassen.
Das ist zumindest meine Erfahrung.

-------------------------------------------
Schlußwort:

Du hast nun hoffentlich gelernt, dass Du als verantwortlicher Admin wissen musst, in welcher Kodierung ein Backup vorliegt und mit diesem Wissen auch die Möglichkeit hast die Daten korrekt wieder einzuspielen.
Anhand der Fülle an Informationen, die man für eine eindeutige Beurteilung benötigt (Von was für einem MySQL-Server stammt das Backup? In welchem Format wurde es gespeichert?), wird auch klar, dass viele Hilfeversuche ohne diese Informationen zum Scheitern verurteilt sind. Mir selbst geht das nicht anders.
(Achte mal spaßeshalber in Hilfe-Threads anderer Foren darauf, dass so gut wie nie jemand die Gegenfrage stellt in welcher Kodierung das Backup eigentlich geschrieben wurde. Alle versuchen zu helfen, aber eigentlich kann es ohne diese Info keiner. Da wird häufig wild rumprobiert - meistens erfolglos. Wink )

Aber: wenn Du das alles aufmerksam gelesen hast, hast Du jetzt das notwendige Hintergrundwissen und Rüstzeug, um unterschiedlichste Umzüge zu meistern.

Ich habe mir hier jetzt stundenlang die Finger wund getippt, damit Du Bescheid weißt.
Mach was aus diesem Wissen. Wink

Allzeit funktionierende Backups wünsche ich Dir.

_________________
Gruß / Greetings, DSB

Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.


Last edited by DSB on 2012-10-03, 21:43; edited 57 times in total

OfflineView user's profileSend private messageSend e-mailVisit poster's website    
Anzeigen











Posted:    Anzeigen Back to top


    
DSB
Developer
Developer




Age: 45
Joined: 30 Apr 2004
Posts: 17254
Location: Herdecke


germany.gif

PostPosted: 2008-02-19, 15:20    (No subject) Reply with quoteBack to top

Zum Diskussions-Thread zu diesem Artikel:
http://forum.mysqldumper.de/viewtopic.php?t=3418

_________________
Gruß / Greetings, DSB

Teigwaren heißen Teigwaren, weil sie Teig waren.
Diejenigen, die lautstark darüber diskutieren, warum es nicht geht, mögen bitte jene nicht stören, die es gerade tun.

OfflineView user's profileSend private messageSend e-mailVisit poster's website    
Display posts from previous:      
Post new topicReply to topic


 Jump to:   


Show permissions
Similar topics
Topic Author Forum Replies Posted
No new posts Die Umlautproblematik - was, wieso, w... Wombat Bedankomat-Ecke :-) 0 2012-08-02, 06:48 View latest post
No new posts Wieso wird Ordner "Work" im... sfera-haiza Allgemeine Fragen zu MySQLDumper 7 2011-09-12, 17:54 View latest post
No new posts Frage zum Artikel "Die Umlautpro... rwhs Allgemeine Fragen zu MySQLDumper 14 2010-06-17, 03:17 View latest post
No new posts Sticky: Diskussion zu: Die Umlautproblematik ... DSB Gelöst/Erledigt 120 2008-02-19, 15:01 View latest post
No new posts Die Umlautproblematik - was, wieso, w... DSB Gelöst/Erledigt 1 2007-02-04, 01:24 View latest post

 
CrackerTracker © 2004 - 2016 CBACK.de

Powered by Orion based on phpBB © 2001, 2002 phpBB Group
CBACK Orion Style based on FI Theme
All times are GMT + 2 Hours

phpBB SEO