DB Fehler nach Migration

  • Daniela Möllmann

    (@soulbalancerdanni)


    vor 4 Jahren

    Hallo zusammen,

    unsere Website wurde vor ein paar Monaten umgezogen und die DB migriert. Seither haben wir nur noch Probleme und unser Entwickler ist nicht greifbar, ich versuche mir jetzt selbst zu helfen.

    FEHLER NUMMER 1:

    Ich habe rausgefunden, dass ein typischer Migrationsfehler aufgetreten ist.
    –> #Nach Datenbank-Migration: Produktzugriff geht nicht mehr
    bei Datetime-Feldern, die leer waren (also den Wert NULL hatten), wurde durch die Migration 0000-00-00 00:00:00 eingetragen.

    Ich habe mir via PHP MyAdmin die Tabellen und Felder angeschaut und gesehen, dass der datetime Fehler in allen Tabellen zu finden ist.

    Ich bin keine Entwicklerin, kenne mich ein klein wenig aus, die Bearbeitungsmaske über den Hoster PLESK (und dort PHP MyAdmin) sieht für mich gut nutzbar aus. Und wenn ich jetzt alle Tabellen durchgehe und das ändere, ist mir das egal. Dauert sicher lange, aber dann ist es erledigt.

    Ich brauche bitte nur einmal Hilfe bei der korrekten Notation. Wenn ich eine Tabelle in der Struktur aufmache, mir ein Feld vom Typ „datetime“ öffne, habe ich ein paar Spalten, die zu bearbeiten sind:

    Typ: datetime (korrekt)
    Standard: Wie defininiert: Freitextfeld mit der Angabe 0000-00-00 00:00:00 –> hier ist also der Fehler. Ich kann das Feld umstellen auf:
    – Kein(e)
    – NULL
    – CURRENT_TIMESTAMP
    Dann gibt es eine Spalte Null; da steht dann später Ja oder Nein drin (wenn ich bei Standard z.B. NULL eingetragen habe, kommt dort ein Häkchen rein).

    Wäre das der korrekte Weg? Bei Standard NULL auswählen, Häkchen bei Null? Das Ganze sieht dann so aus (Bsp.):
    ALTER TABLE wp_digimember_product CHANGE created created DATETIME NULL DEFAULT NULL;

    In dem Bsp. wäre es wahrscheinlich richtiger, CURRENT_TIMESTAMP zu nehmen. Ich würde jetzt so vergehen und mir alle datetime-Felder ansehen und schauen ob es NULL oder CURRENT_TIMESTAMP sein müsste, aber in jedem Fall dann die Änderung vornehmen.

    FEHLER NUMMER 2

    Dann werden bei uns keine IDs mehr vergeben, größtes Problem gerade bei Digi Member. Ich gehe mal schwer davon aus, dass dies ebenfalls an der DB-Migration gab, denn vorher lief das alles.

    Auch hier eine Frage für die korrekte Notation.
    Bei vielen DB-Tabellen steht für das Feld ID der Typ Integer INT(10).
    Feld: id
    Typ: int
    Länge/Wert: 10
    Standard: wie definiert: 0
    Attribute: unassigned
    Null: Häkchen gesetzt

    Sieht dann in der Vorschau dort so aus (Beispiel DigiMember Product ID): ALTER TABLE wp_digimember_product CHANGE created created DATETIME NULL DEFAULT NULL;

    Das ist sicher auch falsch. Was müsste denn dort stehen, damit wieder IDs vergeben werden?

    Ich würde mich sehr über Hilfe freuen.
    Vielen, vielen Dank!

    Daniela

    Die Seite, für die ich Hilfe brauche: [Anmelden, um den Link zu sehen]

Ansicht von 9 Antworten – 1 bis 9 (von insgesamt 9)
  • Moderator Hans-Gerd Gerhards

    (@hage)

    vor 4 Jahren

    Hallo,
    mögliche Lösungen für eine Reparatur – aber bitte auf jeden Fall erst mal zumindest die DB sichern:

    Viele Grüße
    Hans-Gerd

    bscu

    (@bscu)

    vor 4 Jahren

    Vor ein paar Monaten? Und jetzt erst versucht ihr das zu reparieren? Respekt, eilig scheint ihr es nicht zu haben 🙂 🙂 🙂

    Ich befürchte, die erste Migration ist in die Hose gegangen und mit dieser kaputten Migration wirst du vermutlich nichts mehr anfangen können. Die Datenbank ist geschrottet und wird sich so leicht nicht mehr reparieren lassen.

    Wenn ihr noch Zugriff auf die Seite, von der migriert wurde, habt, könnte man das wieder gerade biegen, oder wenn ihr ein komplettes Backup inkl. Datenbank von der Seite habt. Aber ohne dies sehe ich schwarz.

    @hage
    Glaubst du, die Datenbank ist physikalisch defekt? Ich glaube eher, dass diese schon bei der Migration zerschossen wurde.

    • Diese Antwort wurde geändert vor 4 Jahren von bscu.
    Thread-Starter Daniela Möllmann

    (@soulbalancerdanni)

    vor 4 Jahren

    Hi zusammen,

    vielen Dank! Na ja, wir haben es schon eilig, versuchen uns seit Wochen so zu helfen; den DB-Zugriff habe ich seit ein paar Tagen und da ich gerade Urlaub habe von meinem anderen Job… kann ich jetzt reingehen und schauen.

    Das klingt nicht so gut, was ihr da schreibt; ich schau mal, was ich tun kann. Glaube nicht, dass es noch Zugriff auf das alte System gibt. Soweit ich weiß, ist das mittlerweile weg.

    LG Danni

    Thread-Starter Daniela Möllmann

    (@soulbalancerdanni)

    vor 4 Jahren

    also beim Hoster bei den Funktionen „check und repair“ werden keine Fehler gefunden, das System sagt, dass die DB keine Fehler hat. Damit komme ich wohl nicht weiter. Und doch manuell ändern?

    Moderator Hans-Gerd Gerhards

    (@hage)

    vor 4 Jahren

    @bscu: kann natürlich durchaus sein, dass die Datenbank irreparabel ist, aber einen Versuch wäre es wert 🙂
    @soulbalancerdanni: dann versucht doch mal die Reparatur über die wp-config.php. In einem Fall hat das vor einiger Zeit bei einem Problem mit der Datenbank funktioniert. Wenn das allerdings korrekt über phpMyAdmin wie beschrieben durchgeführt worden ist, sehe ich dann leider auch schwarz.

    Thread-Starter Daniela Möllmann

    (@soulbalancerdanni)

    vor 4 Jahren

    Hey @hage : hab ich gemacht, ist einmal durchgelaufen. Danke schonmal für die Anleitung dazu.

    Die falsche Eintragung bei datetime und in Bezuga auf die IDs sind aber noch da.
    Könntest du mir denn helfen, wie dort die Notation sein müsste? Ich würde es zumindest gerne mal ausprobieren, damit wir zumindest vielleicht erstmal ein paar neue Produkte anlegen können, auf die unsere Kunden gerade warten.

    LG Danni

    Moderator Hans-Gerd Gerhards

    (@hage)

    vor 4 Jahren

    Hallo,
    das ist im Rahmen eines Forums wohl kaum möglich und dazu kommt ja noch, dass das ein doch ziemlich exotischer Fall ist.
    Ich würde sicherheitshalber an deiner Stelle die komplette Instanz auf eine lokale Entwicklungsumgebung migrieren, z.B. mit Laragon, Bitnami oder Local by Flywheel. Dann installierst du WordPress und stellst die Seite lokal fertig. Das kann man ganz gut mit dem Plugin Duplicator machen. Wie das im Beispiel von Laragon funktioniert, habe ich hier beschrieben.
    Dann kannst du entsprechende Tests und Lösungsmöglichkeiten auf der lokalen Instanz testen, ohne dass du dir die Datenbank noch mehr zerschredderst.
    Alternativ kannst du dir auch einen Dienstleister suchen, der das möglicherweise reparieren kann. Zu den Erfolgsaussichten kann ich allerdings nichts sagen.
    Viele Grüße
    Hans-Gerd

    bscu

    (@bscu)

    vor 4 Jahren

    #Nach Datenbank-Migration: Produktzugriff geht nicht mehr
    bei Datetime-Feldern, die leer waren (also den Wert NULL hatten), wurde durch die Migration 0000-00-00 00:00:00 eingetragen.

    Das könnte man schnell mit phpMyAdmin korrigieren:

    Update tabelle set Name_der_spalte=NULL where Name_der_spalte=’0000-00-00 00:00:00′

    In dem Bsp. wäre es wahrscheinlich richtiger, CURRENT_TIMESTAMP zu nehmen.

    Nein, wenn vorher der Default NULL war, solltest du das nicht ändern.

    Bei vielen DB-Tabellen steht für das Feld ID der Typ Integer INT(10).
    Feld: id
    Typ: int
    Länge/Wert: 10
    Standard: wie definiert: 0
    Attribute: unassigned
    Null: Häkchen gesetzt

    Ob das falsch oder richtig ist, kann ich nicht beurteilen, das ich mich mit WooCommnerce noch nicht wirklich beschäftigt habe. Aber da der Standard auf 0 gesetzt ist, kann man davon ausgehen, dass diese ID vom Shop-System erstellt wird und nicht per auto_increment erstellt wird.

    WICHTIG: Bevor du überhaupt irgend eine Änderung machst, solltest du die Datenbank mit phpMyAdmin sichern. Auch wenn ich glaube, dass da nicht mehr viel zu retten ist, man muss es ja nicht noch schlimmer machen

    Thread-Starter Daniela Möllmann

    (@soulbalancerdanni)

    vor 4 Jahren

    Hey zusammen,

    vielen Dank für diese Nachrichten 😉 Ich werde es nochmal probieren, weil ich wissen will, ob es klappt. Aber wir haben uns auch entschieden, eine neue Instanz aufzusetzen und den Mitgliederbereich dort komplett neu aufzusetzen; den Shop und den Rest erstmal stehen zu lassen und dann weiter zu entscheiden. Hauptsache unsere Kunden kommen wieder an die Inhalte.

Ansicht von 9 Antworten – 1 bis 9 (von insgesamt 9)
  • Das Thema „DB Fehler nach Migration“ ist für neue Antworten geschlossen.