Habe mal eine Frage. Bei einem Import einer MySQL Datenbank ist etwas schief gelaufen. Da auf dem alten Server MySQL 5.1.51 lief und auf dem neuen nur 5.0.91 sind die Sonderzeichen in allen Kundendaten und Bestellungen fehlerhaft. Die Fehlerhaften Umlaute in Texten von Modulen etc. kann man ja über den Menüpunkt Texte Anpassen korrigieren. Dies ist auch schon geschehen. Hat jemand einen Tipp, ob es vielleicht irgendwie per SQL Script reparierbar ist ? Wenn ich jetzt alle Kundenaccounts durchgehen müsste - bin ich in einer Woche noch nicht fertig.
So konnte in der Zwischenzeit das Problem lösen ;-) Habe ein kleines Program erstellt, welches die Fehlerhaften Umlaute in der Datenbank findet und ersetzt. Wenn mal jemand das Problem hat, das seine Umlaute wie folgt angezeigt werden, kann er sich gerne per Mail bei mir melden. z.B. äöü (entspricht äöü)
Hallo, ich habe das Problem, dass ich mit der Aktion "Texte ändern" alle Umlaute ändern muss. Für ä steht jetzt ä wird aber als ? dargestellt. Das Selbe für ü steht ü sowie für ö steht ö und für ß steht ß Gibt es eine Möglichkeit alle Umlaute zu finden und umzuschreiben?
Hat man eine Chance wenn in der Datenbank für Umlaute nur ein ? steht. Gibt es da auch ne Möglichkeit das zu ändern (automatisch) oder muss man das alles von Hand ändern?
Danke für die Antwort. Wie lege ich die Datenbank denn neu an? Bin da nicht so ein Computerexperte. Heißt das beim Serve eine neue DB anlegen?
Hallo, zunächst mal etwas Basis Wissen das Problem mit dem ? anstelle von Umlauten kommt daher das die Koallition, also die Spracheinstellung der DB, nicht passt. XT, also der Daddy von Gambio ist ein alter Knacker der mit Latain Swedish1 gearbeitet hat. Das ist eine Einstellung die "ein Byte" Chars enthält. Es wird ein Byte pro Zeichen verwendet, also sind 2hoch8 = 255 Zeichen möglich. Die ersten 128 Zeichen sind dabei "normale" Buchstaben und Zahlen, danach kommen Sonderzeichen wie ä, ö... Viel zuwenig um all das Zeichengewussel der Welt auf einmal darstellen zu können. Darum kam Unicode ins Spiel. Bei Unicode werden 2 Byte pro Zeichen verwendet. Das bedeutet : 2 hoch 16 x = 65536 Zeichen. Soviele Buchstaben haben nicht mal die Chinesen...hehe Wenn die DB nun eine Unicode kodierung aufweist muss sie bei jedem Zeichen das 2. Byte "raten" wenn versucht wird swedisch Latain 1 zu verwenden. Da Computer aber grottenschlecht raten können wird eben 00 verwendet. Das führt dazu das ein Wert der eigentlich so aussieht D6A7 zu D600 wird. Das D6A7 würde ein 'ö' bedeuten, aber wenn es in der Kodierung an der Stelle D600 kein Zeichen gibt macht der Compi ein dummes Gesicht und fragt '?' (=häh? in Computersprache) Dasselbe passiert wenn es sich umgekehrt verhält, also versucht wird Unicode Text in eine 1 Byte DB zu schreiben nur das dort eben ein Wert fehlt. Aktuelle Provider geben beim erstellen der DB meist Unicode bzw, UTF vor. Man kann im phpymAdmin sehen welche Einstellung vorliegt: Dann mal eins nach dem anderen... @ Stefan : Wenn du aus einer DB exportierst musst du darauf achten was für Einstellungen vorliegen. Beim Import musst du der neuen DB mitteilen welche Kodierung die Daten haben die importiert werden sollen. Ansonsten nimmt sie an das die Daten in "ihrer" Kodierung vorliegen. Und schwupps...Buchstabensuppe... Das kommt zum tragen wenn du die Import Funktion von phpmyAdmin nutzt. Umgehen kann man das wenn man die Daten per SQL Eingabe reinhaut. In diesem Moment prüft phpmyAdmin was da ankommt und machts richtig. Aber auch nur da. Wenn du ein SQL File hast ohne Einstellung der Koallition - wird die Kodierung der DB vorausgesetzt! Wenn das Problem nur in den Kundendaten vorliegt, dann kannst Du entweder die Tabellen Customers und Addressbook leeren und den Import per Hand durchführen. (Ist nervig, weiß ich...habe Ich auch so machen müssen für knapp 2000 Kunden...bäh.) oder der DB explizit sagen welcher Datentyp da kommt. Im Kopf der Datei muss das etwas wie das hier stehen je nachdem was für Daten du hast. /*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */; /*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */; /*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */; /*!40101 SET NAMES utf8 */; @ rasenmäher Unicode wurde eingeführt um die HTML formatierung loszuwerden. Mit Unicode kann man das ü direkt eingeben. GAMBIO geht von Unicode aus und erwartet keine HTML Tags. Du übergibst mit dem ä Zeichen die der DB nicht bekannt sind. Daher das ? Warum musst Du denn unbedingt die HTML Formatierung nutzen? @ Michael English Also, was kann man(n) tun um die Fragezeichen loszuwerden. Leider hat cmtopchen Recht. Das muss neu gemacht werden. Alle Sonderzeichen aus der DB zu filtern wäre schwierig. Vor allem wenn es sich dabei um ein '?' handelt, das ja durchaus auch korrekt an der Stelle sein kann. Zudem weißt Du ja nicht welches Sonderzeichen gerade dieses ? ersetzt. Sollte dein Shop noch jungfräulich sein installiere nochmal mit den richtigen Einstellungen der DB (also UTF8 Unicode) Die primäre Frage dabei ist welchen Provider Du hast und welche Freiheiten er Dir lässt. Billig oder Massenprovider wie 1und1 nehmen wenig Rücksicht auf ihre Kunden und bieten meist wenig Einstellmöglichkeiten, In der Regel gibts aber ein Adminmenu von dem aus man seine DB's verwalten kann und eine phpmyAdmin installation. Im phpmyAdmin alle Tabellen löschen und danach die Koalition umstellen, neu installieren - fertig. Hoffe ich konnte etwas Licht ins Dunkel bringen, falls nicht gibt es viele, viele Bücher über UniCode und mySQL Leider kann Ich nicht sagen ob Gambio sich an allen Stellen an die Zeichesatzkodierungen hält. Schließlich ist es ein Nachfahre von XT und jede Zeile Code zu prüfen ist fast unmöglich. Aber die Jungs haben schon mächtig was geleistet. Hut ab es grüßt ...der Mac
Wenn die Konvertierung beim Update fehlerfrei verläuft, ja. Wenn nicht, dann hast Du genau dieses Problem...
Vielen Dank für die Erklärung. Ich bin bei allinkl. Leider ist mein Shop nicht mehr "jungfäulich" und bin froh das der einigermaßen wieder läuft. Bin auch leider nicht so bewandert was das löschen und neu machen anbelangt. Heißt das ich auch den gesamten Shop neu insallieren muß? Oder muss man unter PHPmyadmin die Datenbank löschen? wenn ja wie? Und kann ich dann die letzte Datenbanksicherung vom Shop wieder einspielen? Vielen Dank für weitere Eklärungen bzw Lösungsansätze
Hi Michael, ganz so einfach ist das leider nicht. Während des Betriebs werden eine ganze Reihe von Tabellen mit Daten gefüllt. Da verliert man leicht etwas. Besonders wenn schon Bestellungen vorliegen. Ich kann nicht unerwähnt lassen das dieser Vorgang schon einiges Wissen erfordert. Wenn man da nicht absolut sicher ist was man tut kann das bös ins Auge gehen. Von "Datensalat" bis "Shop läuft gar nicht mehr" ist praktisch alles möglich. Wenn Dir also Begriffe wie phpmyAdmin, Tabelle, Feldnamen und SQL im Ganzen völlig unbekannt sind - dann lass das lieber sein Zunächst müsste man wissen was genau du anpassen willst/musst. Dann muss ein Zeitpunkt für das Update ermittelt werden in dem du den Shop offline stelen kannst. Vorzugsweise nachts. Es darf nicht sein das sich Tabellen in Zeitraum der Sicherung, Bearbeitung und wieder einspielen verändern. Wäre fatal wenn sich grad wenn du updatest ein neuer User anmeldet oder eine Bestellung geschrieben wird. Meine Erfahrung sagt das Sonntag auf Montag Nachts ein guter Zeitpunkt ist. haita waita.... Das Problem kann eigentlich nur in Tabellen liegen in denen Texte auf Deutsch hinterlegt werden. Das sind nicht soviele, aber sie sind meist gut gefüllt. ( products, address_book, orders, categories) Von den Tabellen macht man eine Sicherung per phpmyAdmin. Danach in der Sicherungsdatei die ? Zeichen entfernen. Das lann natürlich ein ziemlicher Aufwand werden, je nach Datenmenge. Man kann das mit suchen und ersetzen etwas beschleunigen, birgt aber das Risiko das die Funktion völligen Blödsinn erzeugt. Du solltest dazu mit sowas wie PSPad oder Notepad++ arbeiten. Der Standard Windows Editor ist da keine so gute Wahl. Wenn allles fertig ist löscht Du die betroffenen Datensätze aus der Tabelle und führst einen Import deiner angepassten Datei durch. Nun kommt was Wichtiges: Um nicht wieder in dieselbe Falle zu laufen musst du phpmyAdmin mitteilen welches Format deine Textdatei hat. Die Webserver laufen meist unter Linux. Deine Textdatei kommt aber von Windows. Die beiden haben so ihre Kommunikatiosprobleme.... Beim Zeichenkodierung der Importdatei wählst du nicht UTF-8 sondern das Standard Windows format iso8859-15. Dadurch "weiß" phpmyAdmin das da eine Windows Textdatei kommt und packt alles korrekt in die DB. Bleibt nur noch der Standardsatz : Wenn Sie oder einer Ihrer Mitarbeiter bei dem Einsatz gefasst oder getötet werden müssen wir leugenen sie zu kennen... Viel Glück, Jim es grüßt ... der Mac
Hallo Mac ich danke Dir für die ausführliche Erklärung. Die Vorgehensweise hab ich grob verstanden. Das Programm Notepad++ habe ich. Werde es dann die Tage mal versuchen. Gruß Michael
auch ein Grund warum man den MySQL Dumper nehmen sollte und die Sache mit Windows kein UTF-8 ist grober Unfug.
Leider bemeckere ich seit 5 Jahren vergeblich die Märzschreibung in den Email-Betreffs: 22. MÀrz 2014 sieht für manche ja vielleicht interessant aus, ich finde es eher blamabel und danke unseren sprachbildenden Vorvätern, dass wir wenigstens keinen Oktobär, Septembär, Dezembär und Novembär haben.