Umlaute nach Dump und Update

[antibart]

Hallo,

wie schon vor kurzem musste ich wieder mal einen MySQL-Import machen.

Das ganze innerhalb von 1und1 - also identischer Webspace, zwei verschiedene Domains. Der Kunde will eine zweite, ähnliche Website erstellen und braucht dazu als Arbeitsbasis die Daten der alten DB.

CMS Version der alten Site: 1.4.x

Neues Projekt: 1.6.3


Leider gibt es auch diesmal wieder Probleme mit den Umlauten.

Mit

$config['set_names'] = false;

lassen sie sich leider in diesem Fall nicht beheben.

[antibart]

Vielleicht noch als Zusatzinfo:

Ich konnte dieses mal keinen Datei-Import machen, weil die DB das erlaubte Limit überschritten hat.

Also hab ich gestückelt und die Tabellen in drei Schritten per Copy / Paste erzeugt. Während des Vorgang gab es folgende Meldungen (sinngemaß)

1) CHARSET latin1 passt nicht zu COLLATE utf8_general_ci
Dementsprechen charset auf utf8 geändert und es lief wieder.  

2) Zuviele Zeichen für KEY index_module_templates_by_module_name_template_name` (`module_name`,`template_name`) weil utf 8 die dreifache Menge an Bytes braucht (erlaubt sind 1000)

Also für diese beiden Felder Charset geändert. Danach durfte ich weiter installieren und bis auf die Umlaute ging alles.

[nockenfell]

Zum grundsätzlichen Import:

Ich kenne 1und1 nicht. Falls jedoch verschiedene Systemoperationen  wie

exec
shell_exec
system
dl
passthru
proc_open
proc_close

verfügbar sind, wäre es möglich PHP Shell zu benutzen und den Export sowie Import mit mysqldump zu machen. Soweit mir ist, braucht PHP Shell vorallem proc_open sowie chdir

[antibart]

Danke ... aber würde das in meinem Fall was nützen..?

Ich werde mir auf jeden Fall noch mal die ursprungsdatenbank ansehen. Scheinbar hat  bei Export schon was nicht hingehauen. Denn die Umlaute der alten DB sind auch im Text-Editor betrachtet schon falsch.

Allerdings sehe ich gerade, es bezieht sich nur auf die Umlaute der bestehenden Daten aus der alten DB. Neue hinzugefügte Sonderzeichen gehen.

Zur Not müsste ich nachträglich global  ersetzen. Was allerdings ne Menge Arbeit wird, da es noch ein paar Zeichen mehr sind als nur die Deutschen Umlaute  ... zb euro-symbol

[nockenfell]

Danke ... aber würde das in meinem Fall was nützen..?

Wenn bereits die alte DB ein Problem hatte, bringt dies natürlich nichts. Ansonsten hättest du eine direkte 1:1 Kopie gehabt.

Ev hilft dies:
http://forum.mysqldumper.de/die-umlautproblematik-was-wieso-was-tun-t2313.html
http://forum.mysqldumper.de/dsb-s-umlaut-korrektur-duk-t2406.html

[antibart]

Wenn bereits die alte DB ein Problem hatte, bringt dies natürlich nichts. Ansonsten hättest du eine direkte 1:1 Kopie gehabt.

Zusammen mit dem alten CMS läuft sie ... nur im neuen macht sie Ärger, da  von latin1 auf utf8 umgestellt wurde. Mit Latin wollte es nicht mehr.

http://forum.mysqldumper.de/dsb-s-umlaut-korrektur-duk-t2406.html

Vielen Dank ... mit der DUK Software hat sich zumindest was getan...

nachdem ich dann  in der config.php auch noch mal

$config['default_encoding'] = 'utf-8';
$config['admin_encoding'] = 'utf-8';
$config['set_names'] = true;  

eingestellt habe, sind sehr viel weniger falsche Zeichen übrig. Die muss ich dann wohl oder übel mit "global Ersetzen" umewandeln...

[m266]

Ich kann jedem den MySqlDumper wärmstens empfehlen. Habe damit schon alle möglichen Umzüge gemacht und benutze das Tool auch zur permanenten Datensicherung. Nach jeder Änderung mache ich damit ein Backup und lasse mir die DB nach Hause senden, so dass auch ein Crash beim Provider keine Angst machen muss. Die DB-Größe ist unkritisch, da der Dumper die Sicherung in Intervallen vornimmt und somit die übliche 30sec-Grenze der Scripts umgeht.