Falscher Zeichensatz nach DB-Import

Nach Import einer via BackupDB erstellten dump.sql über das XAMPP-eigene Shell habe ich im localhost einen falschen Zeichensatz. Dazu passende Fehlermeldung in der Shell:

Code:

---

ERROR 1231 (42000) at line 24346 in file: 'D:\path\Database_xxx.sql': Variable 'character_set_client' can't be set to the value of 'NULL'
Query OK, 0 rows affected (0.00 sec)

ERROR 1231 (42000) at line 24348 in file: 'D:\path\Database_xxx.sql': Variable 'collation_connection' can't be set to the value of 'NULL'

---

Wie soll ich damit umgehen?

Schöne Grüße
N.

1) Neue Datenbank anlegen mit Zeichensatz/Kollation = utf8_general_ci
2) Über phpMyAdmin die Datenbank mit dem Backup befüllen

Das sollte dann auch den korrekten Zeichensatz ergeben.

Merci do_while für die prompte Antwort.

Datenbank hatte ich genau mit utf8_general_ci anglegt. Für phpMyAdmin ist das SQL-File mit derzeit etwas über 7 MB zu groß.
Der Datenimport hat übrigens in der letzten Zeit problemlos funktioniert.

Setze in Deiner php.ini unter xampp\php die Werte für upload_max_filesize und post_max_size höher.
Bitte dabei dran denken, dass die filesize größer als size bleibt.
Habe die in meinem XAMPP auf 40M bzw 35M gesetzt.
Dann nochmal mit MyPhpAdmin versuchen.


Gesendet von meinem LG-H815 mit Tapatalk

Zitat:

---

Zitat von Fachinger

Setze in Deiner php.ini unter xampp\php die Werte für upload_max_filesize und post_max_size höher.
Bitte dabei dran denken, dass die filesize größer als size bleibt.
Habe die in meinem XAMPP auf 40M bzw 35M gesetzt.
Dann nochmal mit MyPhpAdmin versuchen.

---

Nach Erhöhen der beiden php.ini-Werte bricht nun der DB-Import ab mit der Meldung:

Zitat:

---

Fehler
Statische Analyse:
1 Fehler wurden während der Analyse gefunden.
1. Fehlender Ausdruck. (near "ON" at position 25)
SQL-Befehl: *Bearbeiten
SET FOREIGN_KEY_CHECKS = ON;
MySQL meldet:
#2006 - MySQL server has gone away

---

phpMyAdmin bietet eine Ausführung des FOREIGN_KEY_CHECKS an, doch sowohl danach als auch nach einem angebotenen Ignorieren der Fehlermeldung lässt sich Contao-Install durchführen...

Zitat:

---

Zitat von Fachinger

Setze in Deiner php.ini unter xampp\php die Werte für upload_max_filesize und post_max_size höher.
Bitte dabei dran denken, dass die filesize größer als size bleibt.
Habe die in meinem XAMPP auf 40M bzw 35M gesetzt.

---

Ich denke, dass mit den Größenverhältnissen muss genau umgekehrt sein, also post_max_size muss größer als upload_max_filesize sein. Aber auch mit entsprechend geänderter Einstellung bleibt es bei der gleichen Fehlermeldung (siehe #5).

Hast du mal reingeschaut in den SQL-Dump? Steht der Befehl da so drin?

Code:

---

SET FOREIGN_KEY_CHECKS = ON;

---

Falls ja, hau den Befehl mal da raus, daran scheitert die ganze Chose ja wohl. Oder probier notfalls mal "1" statt "ON".

Zitat:

---

Zitat von Neolith

Ich denke, dass mit den Größenverhältnissen muss genau umgekehrt sein, also post_max_size muss größer als upload_max_filesize sein. .

---

So sind die Angaben in meiner php.ini und so funktioniert es bei mir mit ein 27Mb SQL-Datei. Genau wegen dieser Datei hatte ich die Werte anhand der Angaben aus der Fehlermeldung im MyPhpAdmin hichgesetzt

Gesendet von meinem LG-H815 mit Tapatalk

Welche MySQL Version?

Zitat:

---

Zitat von Spooky

Welche MySQL Version?

---

Wer? Ich?

Gesendet von meinem LG-H815 mit Tapatalk

Nein, @Neolith.

Danke für Mühen und Geduld bislang.

@ tab:

Zitat:

---

Hast du mal reingeschaut in den SQL-Dump? Steht der Befehl da so drin?
Code:

SET FOREIGN_KEY_CHECKS = ON;

Falls ja, hau den Befehl mal da raus, daran scheitert die ganze Chose ja wohl. Oder probier notfalls mal "1" statt "ON".

---

Nein nein, die Befehlszeile taucht im Dump nicht auf. Ich hatte die phpMyAdmin-Fehlermeldung eigentlich auch so verstanden, dass der Befehl vermisst wird. Nun gut, ich habe inzwischen asuprobiert:

- Ohne besagte Zeile
- Zeile mit "ON"
- Zeile mit "1"

Die Zeile hatte ich jeweils ziemlich an den Anfang der Datei gesetzt, zu den anderen SET-Anweisungen.
Effekt: keine Änderung, immer dieselbe Fehlermeldung.


@ Fachinger:

Auf die Größenverhältnisse kam ich, weil bei mir standardmäßig für upload_max_filesize 2M und für post_max_size 8M zugewiesen waren. Inzwischen bin ich auch über eine FAQ in der phpMyAdmin-Dokumentation gestolpert:

Zitat:

---

Please note that post_max_size needs to be larger than upload_max_filesize.

---

Der Grund für "meine" Situation ist jedoch sicherlich an einer anderen Stelle zu suchen.


@ Spooky:

XAMPP 3.2.2 gibt 10.1.28-MariaDB an, und als DB-Client libmysql - mysqlnd 5.0.12-dev - 20150407, via phpMyAdmin v4.7.4.

XAMPP 3.2.2 gibt es nicht, soweit ich das sehe?

Vermutlich die Control Panel Version 3.2.2, die habe ich auch.

Ja, so ist es: XAMPP Control Panel v3.2.2

Ich reiche nach: ApacheFriends XAMPP Version 7.1.11

Inzwischen habe ich die besagte dump.sql auf dem Server in eine neu eingerichteten Datenbank importieren können - ohne Probleme.
Anschließend habe ich lokal eine aktuelle Version von XAMPP installiert (ApacheFriends XAMPP Version 7.2.3 + Apache 2.4.29 + MariaDB 10.1.31 + PHP 7.2.3 (VC15 X86 32bit thread safe) + PEAR + phpMyAdmin 4.7.9 + OpenSSL 1.1.0g). Leider bricht der Import derselben dump-Datei mit unveränderter Fehlermeldung ab, also keine Änderung.

Vielleicht hat ja jemand eine Idee, wo ich bei dieser Situation ansetzen kann.

Interessant wäre doch mal rauszufinden, welcher Teil (Befehle am Anfang, Tabelle, ...) des Dumps den Fehler verursacht - oder ob es an der letztlich nur an der Dateigröße scheitert. Die Fehlermeldung erscheint ja reichlich kryptisch und lässt offenbar nicht so leicht auf die Ursache schliessen. Wie sieht denn der Anfang des Dumps aus?

Kurz zusammengefasst: bei den Importen der DUMPs - bzw. nach den Abbrüchen - gab es manchmal logartige Berichte seitens des phpMyAdmins. Leider waren die nicht kopierbar, sonst hätte ich Auszüge daraus hier einsetzen könnnen, aber sie endeten immer bei einem bestimmten Inhaltselement. Das habe ich schließlich entfernt, und nach dem Löschen der DB-Versionen war die Dump.SQL erstens VIEL kleiner und zweitens anstandslos und ohne irgendwelche Verluste zu importieren.

Den wirklichen Grund für die Situation weiß man jetzt natürlich immer noch nicht, ich harre mal der Dinge...

Besten Dank jedenfalls in die Runde für die Denkanstöße.

Um die Größe des DB-Dumps zu verkleinern, könnte man vor dem Export auch den Suchindex und ggf. die Tabellen für Versionierung/Wiederherstellung leeren und anschließend zusätzlich auch noch eine Optimierung aller Tabellen durchführen lassen. Aber vielleicht hast Du das eh schon alles gemacht.

Zitat:

---

Zitat von xchs

Um die Größe des DB-Dumps zu verkleinern, könnte man vor dem Export auch den Suchindex und ggf. die Tabellen für Versionierung/Wiederherstellung leeren und anschließend zusätzlich auch noch eine Optimierung aller Tabellen durchführen lassen. Aber vielleicht hast Du das eh schon alles gemacht.

---

Ja, besonders die Versionstabelle hat in diesem Falle ordentlich was gebracht. Aber im Ernst: auch die vorherigen etwa 2,6 MB (gezipt) waren bislang kein Problem, zumindest nicht per Konsole. Inzwischen tauchen nach dem Umzug auf den Lokalrechner noch ein paar andere Ungereimtheiten auf - ich will zusehen, dass ich mir das Ganze die Tage noch einmal genauer zu Gemüte führe...