HowTo - MyOOSDumper - Infos, Installation, Update

[Dr.Death]

Chris: Du sollst nicht immer von Dir auf andere schließen.

Wenn die SQL Abfragen utf8mb4 ausgespuckt hat sollte man das auch verwenden.
(Ab utf8mb4 werden nativ Emojis unterstützt)

[HaioPaio]

Bei mir sieht es auf Strato so aus:

Code: Alles auswählen

Variable_name Value
character_set_client utf8mb4
character_set_connection utf8mb4
character_set_database utf8
character_set_filesystem binary
character_set_results utf8mb4
character_set_server latin1
character_set_system utf8
character_sets_dir /opt/RZmysql56/share/charsets/

[Dr.Death]

Dann weißt du ja was du wählen sollst.... siehe Mahonys Beitrag.

[Dler]

Also muß ich das beim Dumper dann auch so einstellen damit die Umlaute passen ?

[Dr.Death]

Was hindert dich denn nun daran es auszuprobieren ?

[Dler]

Ok werde dann berichten.

[Dler]

So ich habe jetzt von meinem Hauptboard php8 und dem dumper 5.0.2 eine sicherung als utf8mb4 gemacht.

Habe dann die sicherung ins kloneboard auch dumper 5.0.2 hochgeladen aber wie auch schon vorher stimmen die umlaute wieder nicht.

Beispiel.

Herzlichen Glückwunsch Testuser

Wie gesagt das problem hatte ich vorher mit php 7.4 und dem dumper 1.2.4 nicht.

Edit:

Habe jetzt im Hauptboard ein Backup von der Datenbank im ACP vorgenommen.

Dann im Kloneboard den Dumper 5.02 aufgerufen und die datei hochgeladen. Und siehe da die umlaute passen.

Herzlichen Glückwunsch Testuser

Also liegst schon daran im Hauptboard mit dem Dumper wo ich das Backup mache.

[LukeWCS]

Ich arbeite noch nirgends mit PHP 8, da die verschiedene Software die ich überall im Einsatz habe meist noch gar nicht für 8 ausgelegt ist. Ich habe jetzt zum testen meine lokale Testumgebung (WAMP) auf 8 gestellt und eine Mantis DB (mit der ich gerade eh arbeite) mit MOD 5.0.2 gesichert und wieder zurückgespielt. Die Umlaute haben gepasst. An PHP 8 dürfte es also eher nicht liegen, jedenfalls nicht ursächlich.

Als nächstes mit einer phpBB 3.3 DB getestet, ebenfalls alle Vorgänge mit PHP 8. Zuerst mit dem Programm mit dem ich schon viele Jahre arbeite eine Sicherung durchgeführt um eine zweifelsfreie Referenz zu haben. Dann eine Sicherung mit MOD erstellt und wieder mit MOD importiert und die Seite im Forum mit dem betreffenden Thema per F5 aktualisiert und dann nochmal zur Sicherheit mit Strg+F5. Umlaute passen ebenfalls. Dann wieder mit meinem Standardprogramm eine Sicherung durchgeführt und mit der ersten verglichen: beide Dumps stimmen exakt überein, bis auf unterschiedliche Zeitstempel des Benutzers "Administrators" und das war auch erwartet, denn ich habe nach dem Import mit MOD ja das Forenthema aktualisiert.

Das heisst, in beiden Fällen hat MOD eine korrekte und vollständige Sicherung erzeugt und diese auch fehlerfrei wieder importiert. Ich kann den Fehler so nicht reproduzieren. Allerdings muss ich dazu sagen: ich bin kein MySQL Experte, ich beschäftige mich immer nur soweit damit, um gezielt ein bestimmtes Problem oder Aufgabe zu lösen. Das hängt damit zusammen, dass ich permanent mit einer Vielzahl von Systemen und Programmiersprachen hantieren muss. Mit MySQL kennt sich Mahony erheblich besser aus und sicher auch Dr.Death.

[Dler]

Ok danke LukeWCS.

[SeewolfPK]

Bin von der Version 4.2.3-dev umgestiegen auf 5.0.3-dev

(4.2.3-dev) 24.02.2021 10:39 nein 89 / 177.798 1.39 MB
(5.0.3-dev) 19.03.2021 19:46 nein 89 / 20.741 605.59 KB

Wie erklärt sich der enorme Unterschied bei den Tabelleneinträgen und der Dateigröße?
Im Forum hat es zwischenzeitlich keine neuen Postings und/oder Löschungen gegeben.