Hallo,
ich dachte ich kann das Problem selbst lösen, aber das zieht dann meist doch einen Rattenschwanz hinter sich her. xD
Folgende Konstellation:
JTL Shop 5 mit importierter Shop4 DB (Blowfishkey ist korrekt, sollte aber für das Problem keine Bedeutung haben)
Als ich Anfang des Jahres das erste Mal die 4er DB importiert hatte, gab es kein UTF8 Problem nach dem migrieren. Also alle Zeichen sauber.
Vor einer Woche wollte ich die 5er DB mit der noch laufendem 4er Shop DB aktualisieren. Nach dem Migrieren gab es Fehler auf die ich keine "Lust" hatte, bzw. feststellte, dass ich scheinbar an einer Stelle zu wenig und an anderer Stelle zu viel importiert hatte. Importiert im Sinne von wiederherstellen (via SQLDumper). Vielleicht ist das schon ein Fehler.
Also alles zurück und die Sicherung wieder eingespielt. Hier hatte ich erstmal keine Fehler mehr entdecken können.
Am nächsten Tag waren die UTF8 Zeichenfehler überall zu finden. Kategorien, News/Blogbeiträge, eigene Boxen, eigene Seiten.
Einzig die Artikelbeschreibungen waren nicht davon betroffen.
Habe mir daraufhin die DB angeschaut, fast alles auf InnoDB und utf8_unicode_ci. Außer die jtlsearch Tabellen.
An anderer Stelle steht für die DB: utf8mb4_general_ci, das Schema aber auf utf8_general_ci. Ich vermute, dass mein Hoster ein Update gemacht hat. Da ja bei der ersten Migration nicht das Problem auftrat. Oder ich bin zu blöd. 😅
Ich habe dann eine neue leere DB erstellt und noch einmal die 4er DB darin wiederhergestellt und dann migriert. UTF8 Problem besteht da auch weiterhin.
Hat jemand eine Idee?
Die letzte Instanz des Testens wäre eine DB via Shop5 zu erstellen und dann die 4er Daten, also nur die Kundendaten, Bestellungen, Rechnungen, Lieferzeug, etc.pp. wiederherzustellen. Oder ich muss das über importieren machen, da der Blowfishkey ja anders ist. Ich möchte die Kundendaten erhalten.
Den Beitrag habe ich eigentlich nur erstellt, weil es kein direktes zurücksetzen der Sprachvariablen gibt. Und beim händischen Umschreiben ich einfach nicht weiß was bei "productDetails;dimensions2d;"Abmessungen (L×H)";1" das "×" sein soll.
Laut Google könnte es ein Ö sein, aber was ist bitte LÖH?
Grüße
holzpuppe
ich dachte ich kann das Problem selbst lösen, aber das zieht dann meist doch einen Rattenschwanz hinter sich her. xD
Folgende Konstellation:
JTL Shop 5 mit importierter Shop4 DB (Blowfishkey ist korrekt, sollte aber für das Problem keine Bedeutung haben)
Als ich Anfang des Jahres das erste Mal die 4er DB importiert hatte, gab es kein UTF8 Problem nach dem migrieren. Also alle Zeichen sauber.
Vor einer Woche wollte ich die 5er DB mit der noch laufendem 4er Shop DB aktualisieren. Nach dem Migrieren gab es Fehler auf die ich keine "Lust" hatte, bzw. feststellte, dass ich scheinbar an einer Stelle zu wenig und an anderer Stelle zu viel importiert hatte. Importiert im Sinne von wiederherstellen (via SQLDumper). Vielleicht ist das schon ein Fehler.
Also alles zurück und die Sicherung wieder eingespielt. Hier hatte ich erstmal keine Fehler mehr entdecken können.
Am nächsten Tag waren die UTF8 Zeichenfehler überall zu finden. Kategorien, News/Blogbeiträge, eigene Boxen, eigene Seiten.
Einzig die Artikelbeschreibungen waren nicht davon betroffen.
Habe mir daraufhin die DB angeschaut, fast alles auf InnoDB und utf8_unicode_ci. Außer die jtlsearch Tabellen.
An anderer Stelle steht für die DB: utf8mb4_general_ci, das Schema aber auf utf8_general_ci. Ich vermute, dass mein Hoster ein Update gemacht hat. Da ja bei der ersten Migration nicht das Problem auftrat. Oder ich bin zu blöd. 😅
Ich habe dann eine neue leere DB erstellt und noch einmal die 4er DB darin wiederhergestellt und dann migriert. UTF8 Problem besteht da auch weiterhin.
Hat jemand eine Idee?
Die letzte Instanz des Testens wäre eine DB via Shop5 zu erstellen und dann die 4er Daten, also nur die Kundendaten, Bestellungen, Rechnungen, Lieferzeug, etc.pp. wiederherzustellen. Oder ich muss das über importieren machen, da der Blowfishkey ja anders ist. Ich möchte die Kundendaten erhalten.
Den Beitrag habe ich eigentlich nur erstellt, weil es kein direktes zurücksetzen der Sprachvariablen gibt. Und beim händischen Umschreiben ich einfach nicht weiß was bei "productDetails;dimensions2d;"Abmessungen (L×H)";1" das "×" sein soll.
Laut Google könnte es ein Ö sein, aber was ist bitte LÖH?
Grüße
holzpuppe
