Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 
DirkB
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 2
Dabei seit: 08 / 2021
Betreff:

Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 · 
Gepostet: 27.08.2021 - 00:28 Uhr  ·  #1
Hallo Support,

ich habe ein CF4 Forum neu installiert und dann die Datenübernahme von einem bestehenden CBack Orion2 Forums angestoßen. Alles nach Anleitung - Installtion in gleiche Datenbank.

Nun bricht die Datenübernahme aber mit einer roten Box ab und es heißt "Fehler 256 - Bei der Ausführung der Datenbankabfrage ist ein Fehler aufgetreten!".

Nun habe ich mir beholfen, in dem ich in der URL dann den Parameter step oder substep selbst hochgezählt habe und erneut aufgerufen. Ein mühsames Unterfangen, was extrem Zeit kostet und man überspringt diverse Nummern damit es endlich vorangeht.

Wie wäre der offizielle Weg, mit solchen Fehlermeldungen umzugehen? Das Handbuch sagt dazu nichts.
Gibt es eine Möglichkeit, dass die Fehler zwar gelistet werden, dann aber dennoch ohne Abbruch weitergemacht wird?

Woran liegt es überhaupt, dass es zu solchen Fehlern kommt?

Gruß aus Hamburg,

Dirk
Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.
cback
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 38
Homepage: cback.net
Beiträge: 17613
Dabei seit: 12 / 2003
Betreff:

Re: Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 · 
Gepostet: 27.08.2021 - 10:41 Uhr  ·  #2
Hallo Dirk!

Tut mir Leid zu hören, dass der Konverter nicht wie eigentlich gedacht (und üblich) in einem Rutsch bei Dir durchläuft!

Das Orion/phpBB2 ist eines der ältesten Systeme, die vom Konverter noch unterstützt werden (eingestellt 2005) und bei damaligen Altsystemen gab es leider oftmals noch keinen so hohen Prüfstandard was das abspeichern von Daten angeht. Dies kann also dazu führen, dass die Datenvorlage für den Konverter in seltenen Fällen einmal mit korrupten Daten zu tun hat oder sogar eine spätere Modifikation/Änderung am alten System / an der alten DB Struktur selbst die DB Vorlage so geändert hat, dass der Konverter vielleicht nicht mehr damit arbeiten kann, weil dieser natürlich erst einmal nur auf das "Out Of The Box" Orion/phpBB2 von damals ausgelegt wurde. Mich überrascht nur ein bisschen, dass bei Dir sogar das Übertragen der Useraccounts hier schon ein Problem macht, normalerweise hat man - wenn es denn mal zu einem Fehler kommt - den eher im Bereich der komplexeren Datensätze wie beispielsweise der Posts.


Zunächst vorab noch ein paar allgemeine Tipps, wie Du eventuelle Fehler beim Konvertieren von einem ganz alten System vermeiden / einschränken kannst:

Wenn Du die Konvertierung neu ansetzt, musst Du leider die Installation des CF4 in der DB am Besten immer noch einmal ganz neu machen, damit keine Restdaten in der DB sind, die dann vielleicht bei einem erneuten Übernahmeversuch kollidieren (z.B. doppelte Primärschlüssel). Auch sollte das Prefix Deiner CF4 Installation ein anderes sein als das Deines alten Forums (aber in der selben DB, das hast Du soweit ich lese aber absolut korrekt gemacht). Im Fehlerfall ist das mit dem Installation wieder aus der DB löschen (nur die Tabellen vom CF4!) & nochmal ganz neu ansetzen nervig, aber üblicherweise rennt der Konverter eigentlich sauber, aber manchmal steckt bei so Datentransfers der Fehlerteufel irgendwo in der Ecke.

Auch ist empfohlen, dass Du beim Orion am Besten bei der Installation den Accountnamen verwendest, der im Orion die User-ID 2 hatte (also üblicherweise der Primäradmin / Primäraccount im phpBB2). In dem Fall müsste er beim Konvertieren nämlich keine Nutzer-IDs umrechnen, was eventuelle Probleme bei falschem Datenbestand auch minimiert.

Dann ist auch ein guter Tipp: Mache die Konvertierung eines solchen Altsystems erst einmal mit den absoluten Mindestanforderungen des CF4, also ruhig den Webspace beim Konvertieren von Orion erst auf einer PHP 5.6 lassen und - falls nicht schon gemacht - auch den MySQL Server NICHT auf den strikten Modus stellen, wie er ab MySQL 5.7 oftmals per Default aktiviert ist. Das deaktivieren dieses Strikten Modus während einer Konvertierung löst eigentlich die meisten Probleme dieser Art, da bei nicht ganz korrekten Altdaten der MySQL Server still eine Übertragung in den richtigen Datentyp macht oder auch mal fehlende Werte / Defaultwerte kompensiert, während er auf strict einfach direkt abbricht und einen fatalen Fehler aus einem eigentlich kleinen Problemchen macht. Das kann beim der Übernahme von Altdaten, die noch nicht so typengesichert waren, durchaus gerne mal "knallen". Sobald die Konvertierung abgeschlossen wurde kannst Du dann sowohl auf neuere PHP Versionen wechseln (PHP7 & 8 sind sogar empfohlen) und dann durchaus auch wieder bei MySQL auf strict gehen wenn gewünscht. Also das am Besten noch zuerst prüfen und mit anderen Worten der Datenkonvertierung erst einmal die Serverkonfiguration so fehlertolerant wie möglich machen, gerade bei einem so alten Datenstand wie vom Orion.


Jetzt aber zum Vorgehen wie Du zunächst den Fehler ggf. einschränken und damit beheben kannst:
In dem roten Kästchen von Deinem Screenshot steht der Query, der nicht richtig funktioniert hat. Kopiere einmal den gesamten Query und füge ihn in ein Datenbank Tool wie beispielsweise phpMyAdmin im "SQL" Tab Deiner CF4 Datenbank ein. Dort müsstest Du dann vom MySQL Server eine genauere Fehlermeldung erhalten, was genau bei der Ausführung des Querys nicht funktioniert hat. Da hapert vermutlich irgend ein Default Wert oder ein Feldwert der vom Altsystem nicht richtig rüberkam. Das könnte Dir zumindest zum Beheben des Problems ein paar Anhaltspunkte geben wo Du kurz die DB oder gar einen Abschnitt im Konverter ändern könntest, damit der Konverter ohne Probleme läuft.

Als letzte Reißleine könntest Du auch versuchen die DB von Deinem alten Forum einmal lokal zu duplizieren und dann die Installation / Konvertierung des CF4 in einer lokalen Umgebung (z.B. XAMPP bei Windows, MAMP bei Mac) auszuführen. Manchmal gibt's irgendwo in der Serverkonfiguration eine Hürde oder Überlauf und lokal klappt es dann häufig besser. Die fertig konvertierte DB kannst Du dann wieder online umziehen, beispielsweise mit dem MySQLDumper.

Als aller letzte Möglichkeit könntest Du auch noch versuchen den Standard phpBB2 Konverter "mit Attachment Mod" auf Deine Daten anzusetzen statt dem Orion Konverter. Dieser fragt sozusagen das Minimum an zu übertragenden Daten an und eventuelle eigene Modifikationen am Orion und deren DB sind dann nicht ganz so schnell zu kritisch für die Übertragung. Wenig Mods haben damals in die direkten phpBB2 Blankofelder eingegriffen.

Ich hoffe sehr das hilft Dir dem Problem auf die Spur zu kommen!

Übrigens noch zu Deiner Frage mit dem unterdrücken: Der Fehler 256 kommt direkt von Deinem DB Server und wird vom CF4 dann eigentlich nur als Problem ausgegeben. Das heißt ein angefragter Query / Transaction ist auf DB Ebene komplett gegen die Wand geknallt. Diesen Fehler kann man also leider nicht ignorieren oder überspringen, da mitunter dann die ganze Datenstruktur inkorrekt wäre wenn man einfach weitermacht. Da müsste man also leider auf tiefere Ursachenforschung gehen und das eigentliche Problem identifizieren und ggf. über einen Codeeingriff beheben. - Sofern das Deaktivieren des MySQL Strict Modus auf Deinem Server selbst nicht selbst schon das Problem löst, weil Daten dann länger mal von der DB ein bisschen geradegebogen werden bzw. der DB Dienst etwas fehlertoleranter reagiert und nur wirklich kritische Probleme als Grund für einen Stop wertet.

Viele Grüße,
Chris
DirkB
Benutzer
Avatar
Geschlecht: keine Angabe
Beiträge: 2
Dabei seit: 08 / 2021
Betreff:

Re: Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 · 
Gepostet: 27.08.2021 - 23:56 Uhr  ·  #3
Hallo Chris,

danke für die ausführliche Antwort ...

Das mit dem strikten Modus auf dem SQL-Server kann man schon mal vergessen.
Der Hoster erlaubt keine Umstellung in einer geshareten Umgebung - und die wenigsten Forenbetreiber werden einen exklusiven SQL-Server haben.

Also zweite Option: bemängelten SQL-Befehl testen und Fehleranalyse.

Der erste gemeldete Fehler lautet:
"Beim ausführen der Datenbankabfrage ist ein Fehler aufgetreten!
INSERT INTO cf4_banlist ( `ban_ip`, `ban_user`, `ban_email`, `ban_set_time`, `ban_end_time`, `ban_reason` ) VALUES ( '', '', '*@mailinator.com', 1630099697, 0, '' )"


Das Problem ist, dass die Spalte ban_user als mediumint(8) definiert ist und eine Zahl erwartet.

Manuelle Änderung auf ...
... VALUES ( '', 0, '*@mailinator.com', 1630099697, 0, '' )
... funktioniert dann testweise.

Dazu meine Frage: Wo kommt der ban_user Wert '' her?

In der Ausgangstabelle hat ban_userid den Wert 0 (siehe Screenshots).

Gruß, Dirk
Der an diesem Beitrag angefügte Anhang ist entweder nur im eingeloggten Zustand sichtbar oder die Berechtigung Deiner Benutzergruppe ist nicht ausreichend.
cback
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 38
Homepage: cback.net
Beiträge: 17613
Dabei seit: 12 / 2003
Betreff:

Re: Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 · 
Gepostet: 28.08.2021 - 00:27 Uhr  ·  #4
Hallo Dirk,

bitte sehr gerne!

Schade, dass Du das bei Deinem Hoster auch nicht über eine individuelle Konfigurationsergänzung ändern kannst, bei manchen Shared Hostern kannst Du so grundlegende Parameter wie z.B. PHP Memory Limits, Ausführungszeiten, Fehlermodi manchmal über Einstellungsseiten anpassen. Das würde dann vermutlich die größte Hürde die Du gerade hast direkt wegschieben und es müsste dann ohne Probleme laufen. Manche Hoster können es aber auch bei Shared Umgebungen nach Anfrage für einen Kunden temporär ausschalten / umstellen, also ggf. mal den Hoster fragen, ob das möglich wäre das MySQL Strict vorübergehend abzuschalten bis Du mit dem Konvertieren fertig bist.

Ich würde Dir an dieser Stelle aber dann wirklich empfehlen den Konvert in einer Lokalen Umgebung zu machen und die fertige DB später wieder zu übertragen. Konvertieren von Orion im strikten MySQL Modus wenn es schon beim Banlisten Schritt losgeht mit den Problemen wird sonst vermutlich sehr müßig werden, gerade wenn Du sehr viele Daten "rüberschaufeln" musst. Also am Besten lokal mit XAMPP (Win) oder MAMP (Mac) fix eine PHP/MySQL Umgebung aufsetzen, dort entsprechend Strict in der MySQL Config abschalten und in der PHP Konfiguration am Besten direkt Memory Limit auf mind. 128M und Ausführungszeit auf 60 oder gar 90 Sekunden (dann konvertiert er auch schneller, da mehr Ressourcen verfügbar sind; lokal darf man da gerne mal ein bisschen übertreiben :) ). Deine Orion DB z.B. mit dem MySQLDumper übertragen, CF4 Lokal installieren und konvertieren lassen, fertig konvertierte DB Online zurückschieben. (Im Handbuch unter "Eine lokale Kopie übertragen" näher beschrieben). Das macht Dir vermutlich den Zeitaufwand insgesamt deutlich weniger als wenn Du Online immer wieder bei Problemen nachsteuern müsstest. Plus Du sparst generell Lokal sehr viel Zeit für den Konverter, da die Zeiten für den Verbindungsaufbau zu den Zwischenschritt-Seiten im Grunde wegfällt.

Der leere Wert kommt hier wohl übrigens von einer Definition mit Leerwerten in Deiner Orion Banliste wo ein eigentlich als Int erwarteter Wert vermutlich NULL ist. Für diesen Schritt würde ich dann fast empfehlen mal die Quell-Banlist Tabelle (also die von Deinem Orion) zu leeren, damit er da gar nichts übernehmen muss. Ich werde mir dieses Phänomen allerdings auch selbst nochmal auf die Optimierungsliste setzen, damit ich beim nächsten CF4 Update im Orion Konverter da vielleicht auch noch eine Abfangroutine einbaue.

Da Deine andere Fehlermeldung von gestern aber sich schon auf die Usertabelle (also ein Schritt weiter im Konverter) bezog und es da mit den Problemen anscheinend so weitergeht empfehle ich Dir eher aber das Lokale, sonst bleibst Du vermutlich immer wieder irgendwo hängen bis alles korrekt übertragen ist.

Solche Typenfehler fängt der Konverter zwar schon von Haus aus so gut er kann ab, aber alle Szenarien kann man leider bei der Fülle an Boardzuständen & Systemkonfigurationen nicht abdecken ohne da notfalls etwas nachsteuern zu müssen. Insbesondere dann, wenn man alle strengen Regeln des Strict Modus auch noch erfüllen müsste bei Quelldaten die mal ohne Strict Modus entstanden sind.


Viele Grüße und schon mal ein schönes Wochenende (bei weiteren Fragen ist der Support ab Montag Vormittag dann wieder hier verfügbar für die Antwort)
Chris
oxpus
Benutzer
Avatar
Geschlecht:
Herkunft: Irgendwo im Internet auf Server 127.0.0.1
Alter: 54
Homepage: oxpus.net
Beiträge: 2153
Dabei seit: 05 / 2004
Betreff:

Re: Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 · 
Gepostet: 28.08.2021 - 12:47 Uhr  ·  #5
Hallo Chris,

der Fehler im Converter ist schnell gefunden und behoben (und viel besser, als an der Datenbank herumzuschrauben):

@Dirk
Bitte in der Datei /setup/converters/orion.php nach der Zeile
Code
        'ban_user'    => $temp['ban_userid'],

suchen und diese Zeile durch den Code
Code
        'ban_user'    => (int) $temp['ban_userid'],

ersetzen.
Dann sollten zumindest "leere" Felder durch eine echte "0" ersetzt werden, was die Datenbank dann wieder korrekt verarbeitet.
Alternativ könntest Du auch die Zeile durch
Code
        'ban_user'    => intval($temp['ban_userid']),

ersetzen, um sogar bei bestehenden Inhalten in der Spalte "ban_userid" ausschließlich nummerische Werte, alternativ bei leeren Feldern eine "0" zu übertragen.

Das hängt letztlich davon ab, welche Werte in der ursprünglichen Tabelle enthalten sind.
cback
Admin
Avatar
Geschlecht:
Herkunft: Saarland
Alter: 38
Homepage: cback.net
Beiträge: 17613
Dabei seit: 12 / 2003
Betreff:

Re: Datenübernahme eines CBack Orion2 Forums bricht ständig ab

 · 
Gepostet: 30.08.2021 - 12:28 Uhr  ·  #6
Hi Karsten,

vielen Dank für Deine Ergänzung! Der von Dir vorgeschlagene Weg ist auf jeden Fall der elegantere Ansatz für das Problem im Strict Modus und damit gut, dass Du diesen auch aufgezeigt hast. 👍

Ich wollte jetzt hier für den Support eher den Weg des geringeren Widerstandes vorschlagen, da nicht ganz klar ist, ob in Folgeschritten im Strict Modus beim Orion / phpBB2 nicht noch weitere solcher Stellen auftreten könnten und das "tiefere" Debugging dann mitunter ein bisschen nervig und frustrierend werden kann, gerade wenn man seine Daten mal fix umziehen möchte und bei Abbruch immer wieder neu ansetzen müsste. Beim optimieren der Konverter für Strict in der nächsten Version bzw. dem nochmal näheren Prüfen auf solche Sonderfälle wird allerdings die Lösung für "ausbrechende" Datensituationen so aussehen und behandelt wie in Deinem Vorschlag. :)

Viele Grüße,
Chris
Gewählte Zitate für Mehrfachzitierung:   0

Registrierte in diesem Topic

Aktuell kein registrierter in diesem Bereich

Die Statistik zeigt, wer in den letzten 5 Minuten online war. Erneuerung alle 90 Sekunden.