Scheiße, kann nicht einfach einmal was funktionieren?

Cheyenne · December 16, 2011, 11:18pm

Hoi,

Kann mir jemand diese Fehlermeldungen entschlüsseln? (Datenbankrestore)

Ich krieg ne ältere Version meines Shops inclusive Datenbank nicht zum rennen…

Jemand ne Idee?

Gruß Ralf

Henning_Kockerbeck · December 17, 2011, 2:12am

Variable ‘character_set_client’ can’t be set to the value of ‘NULL’
Während ein MySQL-Dump wieder eingespielt wird, merkt sich MySQL an verschiedenen Stellen die Werte einiger Einstellungen. Diese Werte werden später wieder gesetzt, für den Fall, dass sie zwischendrin verändert wurden. Das kann, in “normaler” Sprache formuliert, etwa so ablaufen
Merke Dir den aktuellen Wert von ‘character_set_client’ unter dem Namen @saved_cs_client
Setze ‘character_set_client’ auf den Wert XYZ
Tue, wofür auch immer der Wert XYZ gebraucht wird
Setze ‘character_set_client’ wieder auf den Wert, den Du Dir in @saved_cs_client gemerkt hast
Dein Problem ist, in der Variablen @saved_cs_client steht kein Wert. NULL steht bei Datenbanken nicht für 0, sondern für “ich hab keine Ahnung, was hier hinkommt, dafür hab ich keinen Wert”. MySQL beschwert sich im Prinzip, “Ich soll ‘character_set_client’ auf den Wert aus @saved_cs_client setzen, aber da ist kein Wert drin”.

Schau Dir alle Statements in Deinem Dump an, die eine Tabelle erzeugen (CREATE TABLE). Wenn danach ein

/*!40101 SET character_set_client = @saved_cs_client /;
steht (und das dürfte immer der Fall sein), muss davor auch etwas wie
/!40101 SET @saved_cs_client = @@character_set_client /;
stehen. Ein vollständiger Block zum Erzeugen einer Tabelle kann etwa so aussehen
DROP TABLE IF EXISTS oxacceptedterms;
/!40101 SET @saved_cs_client = @@character_set_client /;
/!40101 SET character_set_client = utf8 /;
CREATE TABLE oxacceptedterms (
OXUSERID char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
OXSHOPID char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT ‘’,
OXTERMVERSION char(32) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT ‘’,
OXACCEPTEDTIME datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00’,
PRIMARY KEY (OXUSERID,OXSHOPID)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
/!40101 SET character_set_client = @saved_cs_client */;

Zum nächsten Punkt,

… log/EXCEPTION_LOG.txt … failed to open stream: Permission denied …
Der Shop würde gerne in die Datei EXCEPTION_LOG.txt schreiben, hat dafür aber nicht die richtigen Berechtigungen. Und weil er sich darüber beschwert, kommt es zu den Folgefehlern
Cannot modify header informationen - headers already sent by
Das hat etwas mit der Art und Weise zu tun, wie eine HTML-Seite in HTTP übertragen wird, die genaue Erklärung würde hier zu weit führen. Beschränken wir uns darauf zu sagen, dadurch dass die Fehlermeldung über die fehlenden Berechtigungen ausgegeben wird, passiert ein Teil der Übertragung früher als der Shop sie erwartet. Und wenn er später noch etwas an diesem Teil schrauben will, bekommst Du die Meldung “An den Headern kannst Du nichts mehr machen, die sind längst rausgeschickt”.
mysql_real_escape_string() expects parameter 2 to be ressource, boolean given
könnte auf Probleme bei der Verbindung mit der Datenbank hindeuten. “Untechnisch” ausgedrückt heißt die Meldung so viel wie “Der zweite Wert, den Du an die PHP-Funktion mysql_real_escape_string übergibst, sollte eigentlich eine ressource (die Repräsentation einer Verbindung zu einer Datenbank) sein, Du gibst aber einen boolschen Wert (einen Wahrheitswert, also true oder false)”. Das kann passieren, wenn das Öffnen der Verbindung zur Datenbank fehlschlägt. Die entsprechende Funktion gibt dann nämlich nicht die erwähnte ressource zurück, sondern schlicht false, als Signal für ‘hat nicht geklappt’. Mit dieser vermeintlichen ressource will dann später die Funktion mysql_real_escape_string arbeiten und scheitert daran.

Meine Vermutung ist also, aus irgendeinem Grund klappt die Verbindung zur Datenbank nicht. Der MySQL-Server läuft nicht, ist nicht erreichbar, die Zugangsdaten stimmen nicht, der (MySQL-)Benutzer hat nicht die passenden Zugangsrechte zu dieser Datenbank oder was auch immer.

Dann ist da noch

array_keys() … the first argument should be an array
Ein Array ist keine einzelne Variable, sondern gewissermaßen eine Liste von Variablen. Die einzelnen Felder in dieser Liste werden über Schlüssel (keys) angesprochen. Die Funktion array_keys() stellt eben diese Schlüssel aus einem Array zusammen. Das klappt in Deinem Fall nicht, weil das, worauf Du die Funktion anwendest, kein Array ist. Das kann ein Folgefehler (nicht zwangsläufig vom oben beschriebenen) sein: Du erzeugst ein Array und willst davon später die Schlüssel haben, um sie z. B. der Reihe nach abzuarbeiten (“über das Array zu iterieren”). Allerdings geht beim Erzeugen des Arrays irgendwas schief, und wenn Du später aus dem “Nicht-Array” die Schlüssel auslesen willst, beschwert sich PHP. Was das für ein Array ist, wo es erzeugt wird, warum es nicht richtig erzeugt wird - keine Ahnung, das kann so ziemlich alles sein.

Bis dann,

Henning

Cheyenne · December 17, 2011, 10:01am

Hallo Henning,

na das nenn ich einmal “ausführlich”! Vielen Dank für die Mühe!

Wenn sich MySQL an verschiedenen Stellen Einstellungen merkt, kann die missglückte Einspielung des Dumps (4.4.8) doch schlicht daran liegen, dass sich eine neuere Version der Datenbank (4.5.0) mit gleichem Namen auf dem Server befindet?

Ich hab natürlich versucht den Dump “drüberzubügeln” um eine ältere Version wieder herzustellen… Kann es sein, dass ich die aktuelle Datenbank zunächst löschen muss?

Gruß Ralf

Henning_Kockerbeck · December 17, 2011, 12:57pm

Hallo Ralf,

keine Ursache

[QUOTE=Cheyenne;76394]Wenn sich MySQL an verschiedenen Stellen Einstellungen merkt, kann die missglückte Einspielung des Dumps (4.4.8) doch schlicht daran liegen, dass sich eine neuere Version der Datenbank (4.5.0) mit gleichem Namen auf dem Server befindet?[/QUOTE]
Das würde ich eigentlich ausschließen. Diese Variablen existieren nur während des Einspielens des Dumps; ich wüsste nicht, wie da eine andere Datenbank reinspielen sollte. Es gibt zwar globale Variablen, aber die haben eine andere Syntax.

Stell es Dir vielleicht so vor: Du hast zwei Räume, in denen Du jeweils das Fenster auf geschlossen, gekippt oder ganz geöffnet “einstellen” kannst. Ein Raum ist frisch gestrichen, weshalb Du das Fenster vorübergehend auf “ganz geöffnet” stellen willst. Danach soll es aber wieder in den Zustand, in dem es vorher war. Also schreibst Du auf einen Merkzettel “Das Fenster war vorher geschlossen”. In Deinem Fall ist das Problem, dass Du nachdem die Farbe trocken ist feststellst, Mist, auf meinem Zettel steht ja gar nichts drauf, welchen Zustand hatte das Fenster denn jetzt vorher? Dafür spielt keine Rolle, dass es im Nebenraum ebenfalls ein Fenster gibt

Ich sehe drei mögliche Ursachen, die einigermaßen wahrscheinlich sind:

Du versuchst den Dump auf einer Version des MySQL-Server einzuspielen, die älter oder neuer ist als die Version, mit der der Dump erstellt wurde. Dann kann ich mir vorstellen, dass sich zwischen diesen beiden Versionen die Syntax zum Anlegen von Variablen, die Syntax zum Abfragen von Systemeigenschaften, der Name der Eigenschaft oder etwas in dieser Art geändert hat.
Beim Erstellen des Dumps oder (wahrscheinlicher) beim Einspielversuch ist irgendeine MySQL-Einstellung aktiv, die verhindert, dass die Variablen gesetzt werden.
Der Dump wurde nicht vollständig erstellt, wurde seither irgendwie bearbeitet oder kann aus sonst einem Grund nicht vollständig eingelesen werden. Die Befehle zum Erstellen und Wieder-Auslesen der Variablen steht beispielsweise syntaktisch gesehen in Kommentaren. Ich kann mir vorstellen, dass mal jemand einen übergroßen Dump genommen und alle Kommentare rausgestrichen hat, weil die braucht ja (vermeintlich) eh niemand. Einer blieb dabei stehen, und der versucht eine Variable auszulesen, die nie geschrieben wird. Oder er kommt nicht bis zum Setzen der Variable, weil er vorher bei einem Zeichen, das er nicht verarbeiten kann, aussteigt, etwa ein Akzentzeichen wie é, ein japanisches, kyrillisches, griechisches, … Schriftzeichen oder sonstwas. Das wäre dann ein Problem des Zeichensatzes: Der Dump ist in einem anderen Zeichensatz geschrieben als der aktuelle MySQL-Server es erwartet, oder er ist gar ein Mix verschiedener Zeichensätze. Beide genannten Möglichkeiten geraten aber inzwischen zur argen Kaffeesatzleserei

Bis dann,

Henning

Cheyenne · December 18, 2011, 11:24am

Hallo Henning,

scheinbar war ein Script aktiv, denn als ich beim Einspielen “alle SQL-Scripte anhalten” angeklickt habe, kam keine Fehlermeldung mehr. Ich habe ausserdem angekreutzt, dass die aktuelle Datenbank vor dem einspielen des Dumps gelöscht werden soll…

Allerdings kommt jetzt nach der Abfrage rechts ein weisser Frame und links steht mysqldumper, der orangefarbene LKW darunter und das Menu… und das schon seit einer halben Stunde… Dauert das so lange? Ich meine es kommt nicht einmal eine Statusmeldung…

Gruß Ralf

Henning_Kockerbeck · December 18, 2011, 12:30pm

Hallo Ralf,

ich fürchte, das Skript, das Du angehalten hast, war Dein Dump SQL ist eine Sprache, in der Du mit (nicht allen, aber vielen) Datenbanksystemen wie MySQL kommunizierst. Du sagst beispielsweise

SELECT vorname, nachname FROM kunden WHERE ort=‘Musterhausen’;
und meinst damit
Liefere mir alle Vornamen und Nachnamen aus der Tabelle ‘kunden’, bei denen im Feld ‘ort’ der Wert ‘Musterhausen’ steht.
Ein Dump ist grundsätzlich nichts anderes als eine lange Liste solcher SQL-Statements, aus denen MySQL die Datenbankinhalte rekonstruieren kann.

Dein Dump ist also ein Skript, das in “normaler” Sprache etwa so aussieht (Ausschnitt)

…

Wenn sie vorhanden ist, lösche die Tabelle ‘kunden’

Lege eine Tabelle ‘kunden’ an, mit den Feldern ‘vorname’, ‘nachname’, ‘strasse’ usw.

Erstelle in der Tabelle ‘kunden’ einen Datensatz mit den Werten ‘Michael’, ‘Mustermann’, ‘Musterallee 123’ usw.

Erstelle in der Tabelle ‘kunden’ einen Datensatz mit den Werten ‘Bärbel’, ‘Beispielfrau’, ‘Am alten Bahnhof 5’ usw.
…
Dein Dump ist also ein SQL-Skript. Das Problem ist nicht, dass es ausgeführt wird, sondern dass einzelne Statements darin nicht erfolgreich ausgeführt werden, nämlich eben diese Variablengeschichte.

Ich würde Dir empfehlen, mal einen Fachmann direkt auf das “lebende Objekt”, also auf Deinen Dump, Deinen Datenbankserver usw. draufschauen zu lassen. Mit den Informationen, die ich habe, bin ich so langsam am Ende der Möglichkeiten angekommen, und es artet in Kaffeesatzleserei aus. Und, ohne Dir auf die Füße treten zu wollen, ich habe nicht den Eindruck, dass Du technische Hinweise, wie ich sie in den vorherigen Beiträgen gegeben habe, umsetzen kannst. Die Situation ist gerade ein bisschen, wie wenn Du einen Automechaniker anrufst, ihm sagst “Der Motor klingt aber komisch, an welcher Schraube muss ich drehen?” Dieser Fachmann wird Dir allerdings am Ende eine Rechnung für seine Arbeit schreiben; und weil ich nicht weiß, wo es genau klemmt, kann ich nicht dafür garantieren, dass auch ein Fachmann mit vertretbarem Aufwand (sprich, vertretbaren Kosten) den Shop wiederherstellen kann.

Bis dann,

Henning