MySQL Umzug (Umlautproblem)

S

Simiii

New Member
Hey,

irgendwie hab ich schon wieder ein kleines Problemchen ;)

Ich bin mit meinem Forum auf einen neuen Server gezogen, hat ansich nun alles geklappt, nur mir ist aufgefallen, das Umlaute nicht mehr richtig angezeigt werden.

Dies hängt mit dem Zeichensatz der MySQL Datenbank zusammen.

Auf dem alten System habe ich folgende Einstellungen:

MySQL-Zeichensatz: UTF-8 Unicode (utf8)

Zeichensatz / Kollation der MySQL-Verbindung: UTF-8 Unicode (utf8)

Aber die eigentliche Tabelle hat Latin1

Es klappt ja alles auf dem alten Server, nun habe ich die Tabelle im Latin1 Format mit MySQLDumper gebackupt.

Und wieder alles draufgespielt, überall die selben Einstellungen.

Die Umlautet werden leider nicht richtig dargestellt.

Hat wer einen Lösungsansatz?:)

Vielen Dank
 
Tag,

das Default Charset in der apache2.conf aktivieren.

Code: 
AddDefaultCharset ISO-8859-1

Das sollte dort stehen. Einfach die Kommentierung weg machen und den Apache neustarten.

- Lg
 
dies habe ich nun hinzugefügt, das Part sieht momentan so aus:

AddCharset ISO-8859-1 .iso8859-1 .latin1
AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen
AddCharset ISO-8859-3 .iso8859-3 .latin3
AddCharset ISO-8859-4 .iso8859-4 .latin4
AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru
AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb
AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk
AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb
AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk
AddCharset ISO-2022-JP .iso2022-jp .jis
AddCharset ISO-2022-KR .iso2022-kr .kis
AddCharset ISO-2022-CN .iso2022-cn .cis
AddCharset Big5 .Big5 .big5
AddDefaultCharset ISO-8859-1
# For russian, more than one charset is used (depends on client, mostly):
AddCharset WINDOWS-1251 .cp-1251 .win-1251
AddCharset CP866 .cp866
AddCharset KOI8-r .koi8-r .koi8-ru
AddCharset KOI8-ru .koi8-uk .ua
AddCharset ISO-10646-UCS-2 .ucs2
AddCharset ISO-10646-UCS-4 .ucs4
AddCharset UTF-8 .utf8
Click to expand...

hmm es geht um dieses Forum:

R A P J A M . D E | Forenübersicht


Vielen Dank
 
Hattest du vorher auch Confixx mit den gleichen Einstellungen?

Und hast du schon probiert, die Kollation vorher via PmA auf Latin1 umzustellen?

Hast du noch Zugriff auf den alten Server?

Und warum benutzt du nicht PhpMyAdmin? ;)
 
Ich habe gerad nochmal nachgeschaut, ich hatte auf dem alten Server SysCP.

Und auf dem neuen mache ich alles mit dem OVH Release 2 (Webmin + OVH Modul)

Die Datenbank ist zu groß für ein BackUp mit phpmyAdmin

Auf dem neuen Server wurde die Datenbank mit latin1_swedish_ci Zeichensetzung eingetragen.

Das ist gerad alles etwas verwirrent...

Der alte Server hat die Kolation in der DB: latin1_swedish_ci
MySQL-Zeichensatz: UTF-8 Unicode (utf8)
Zeichensatz / Kollation der MySQL-Verbindung: UTF-8 Unicode (utf8)

Ich versuche die Einstellungen genau so zu übertragen:
Habe mit MySQL Dumper die Datenbank im Latin1 Format übertragen.
Dort herrschen die selben Einstellungen wie auf dem alten Server.

Trotzdem gibt es das Umlautproblem.

Ich weiß gerad einfach nicht weiter...
 
War der Alte dein eigener Server oder war es nur ein gemietetes Webspacepaket?

Mmm... Wie wär's vlt. damit, vorher die Kollation auf Latin1... zu ändern, und dann das Backup wieder einzufügen?

Ich kenne mich leider nur mit pMA aus.

Eine andere Idee wäre noch, die Einstellungen auf dem alten Server nochmal genau durchzugehen, das Backup über pMA zu machen ( vorher müsste man noch die PHP upload file size zu erhöhen ), dann die Kollation über pMA auf den neuen Server wie auf dem Alten Server zu ändern und anschließend das Backup über pMA zu uploaden.

Setz dich dann nochmal mit
Code: 
php_admin_value upload_max_filesize
auseinander. Dann kannst du das Backup auch über pMA uploaden.

Ich hoffe ich konnte dir bislang etwas weiterhelfen.

- Lg
 
Umlautprobleme kann man auch umgehen, indem man keinen Dump macht, sondern direkt die Dateien von MySQL auf den neuen Server verschiebt. (Liegen per default unter /var/lib/mysql)
Du benötigst von dort nur alle Dateien mit dem Namen deiner Datenbank.
Ist zwar eigentlich nicht die 1. Wahl aller Methoden, hat mir bei Serverumzügen aber immer am wenigsten Ärger bereitet :)
Erfordert aber root-Zugriff auf den alten Server, sonst kommst du an diese Dateien nicht ran.
 
So ich habe nun über Root die Datenbank überspielt, nun bekomme ich folgenden Fehler:

SQL-DATABASE ERROR

Database error in WoltLab Burning Board (2.3.6 pl2): Invalid SQL: DELETE FROM bb2_sessions WHERE userid = '2246'
mysql error: Table 'bb2_sessions' is read only
mysql error number: 1036
mysql version: 5.0.44-log
php version: 5.2.5-pl1-gentoo
Date: 16.04.2009 @ 17:35
Script: /wbb2/forum.html
Referer:


Ich denke mal das die Datenbank nun nur Zugriffsrechte vom Benutzer Root hat, daraufhin habe ich

chown mysql:mysql /var/lib/mysql -R

gemacht...

Klappt immernoch nicht...

Hat wer noch eine Idee? :) :)

Vielen Dank
 
Mit den Benutzerrechten des Dateisystems hat das auch nichts zu tun ;)
In der MySQL-Datenbank gibt es eine interne Datenbank, in der die Benutzerrechte für die einzelnen Datenbanken verwaltet werden.

Google mal nach "Mysql Benutzerrechte" und Du wirst sicherlich auf der MySQL-Homepage eine Erklärung finden, welches Attribut was bewirkt und wie es geändert werden kann.
 
Also Benutzer, in diesem Fall "web1sql1" hat für diese Datenbank laut phpMyAdmin alle Rechte dafür.


web1sql1 % datenbankspezifisch ALL PRIVILEGES Nein

Für die richtige Datenbank...

hmm noch wer eine Idee? ;)
 
Kannst du als Benutzer root oder einem gleichwertigen Benutzer mit Zugriff auf alle Datenbanken darauf zugreifen?
Dann müssten die Dateiberechtigungen in Ordnung sein - notfalls starte auch mal den MySQL-Server neu.

Du kannst auch einen REPAIR auf alle Tabellen ausführen und gucken, ob da eventuell etwas nicht ganz in Ordnung ist - das müsste sich dann allerdings auch eigentlich in der Fehlermeldung wiederfinden.
 
You must log in or register to reply here.
Back
Top