Probleme mit Tabellen in DB nach DB Migration

    Hallo und guten Tag!


    Das ganze Thema ist für mich neu, ich konnte hier im Forum keine Lösung für das derzeit bestehende Problem finden.

    Ich habe OpenXe nach Anleitung installiert und den SQL-dump von Xentral v. 24.11.0 mit dem Befehl source in die DB openxe kopiert.

    Im Webinterface von OpenXe wurde mir dann angezeigt, das die Tabelle adresse nicht vorhanden ist.

    Ich habe dann upgrade.sh -db -do ausgeführt aber das Problem war unverändert. Habe dann nochmal upgrade.sh -do laufen lassen aber das Problem bestand noch.

    Dann habe ich mir die fehlende Tabelle aus der original OpenXe DB exportiert und in die Migrations DB importiert. Danach war die Login Seite erreichbar aber ich konnte mich mit meinem Xentral User nicht anmelden.
    Habe nochmal upgrade.sh -db -do -v ausgeführt und eine Fehlermeldung erhalten, die ich leider nicht komplett habe : ALTER TABLE `auftrag` MODIFY COLUMN `*hier stand id...?` rest fehlt mir leider.

    Jedenfalls habe ich die Tabelle auftrag gelöscht und die mir ebenfalls per export/import neu angelegt.

    Jetzt bekomme ich beim Upgrade mit verbose folgenden Fehler:


    ALTER TABLE `auftrag` MODIFY COLUMN `id` int(11) NOT NULL auto_increment;

    PHP Fatal error: Uncaught mysqli_sql_exception: Incorrect table definition; there can be only one auto column and it must be defined as a key in /var/www/html/OpenXE-V.1.11/upgrade/data/upgrade.php:441


    Könnt ihr mir da helfen?

    Mit Datenbanken usw. habe ich bisher kaum Erfahrung, alleine komme ich nicht weiter...


    Edit:

    Die Userdaten habe ich ebenfalls bereits migriert.

    Hi,


    der Import scheint nicht richtig geklappt zu haben. Ich kann Dir nicht raten zu reparieren, besser nochmal die Datenbank löschen und von vorne anfangen.


    Den Datenbankimport machst Du am besten über diesen Befehl:

    Code
    mariadb -u root -p database_name_here < dump_file_name_here.sql


    Ganz vorne in Deine .sql-Datei solltest Du noch vorher folgende Zeilen kopieren:

    Code
    SET SQL_MODE='ALLOW_INVALID_DATES';
SET SESSION innodb_strict_mode=OFF;


    Wenn der Import geklappt hat, das Upgrade über die Konsole laufen lassen.

    Danke für die schnelle Rückmeldung!

    Der Import ist ohne Fehler durchgelaufen.

    Ich bekomme nun wieder den selben Fehler, den ich beim letzten Versuch nicht komplett nennen konnte:


    ALTER TABLE `auftrag` MODIFY COLUMN `shopextid` varchar(1024) NOT NULL COLLATE utf8mb3_general_ci;

    PHP Fatal error: Uncaught mysqli_sql_exception: Specified key was too long; max key length is 3072 bytes in /var/www/html/OpenXE-V.1.11/upgrade/data/upgrade.php:441

    Zitat von Alex

    Entferne mal aus der .sql-Datei die Zeile unterhalb von "CREATE TABLE auftrag", mit dem Text "KEY `shopextid`", dann nochmal importieren, dann upgrade.


    Du kannst auch nur den Abschnitt mit "auftrag" in eine extra-Datei kopieren...

    Jetzt bekomme ich beim importieren den Fehler:

    ERROR 1072 (42000) at line 5436: Key column 'shopextid' doesn't exist in table

    • Neu

    Damit der Thread komplett ist....
    Alex hat mir sehr geholfen, nach einigen Versuchen konnte die Datenbank nun fehlerfrei importiert werden und sie funktioniert!
    Ganz Vorne, am Anfang der SQL Datei habe ich eingefügt:

    Code
    SET SESSION innodb_strict_mode=OFF;
SET SQL_MODE='ALLOW_INVALID_DATES';

    Danach habe ich eine Textsuche nach „CONSTRAINT `“ durchgeführt und alle Zeilen, in denen es vorkommt (hier 11) gelöscht.

    Wichtig: in den vorhergehenden Zeilen muss jeweils ein Komma gelöscht werden damit die Syntax stimmt.

    Anschließend Datei speichern, hochladen und mit mariadb -u root -p openxe < /home/<username>/<dbname.sql> importieren.

    Danach lief ./upgrade.sh -db -v -drop_keys -do ohne Fehler durch (-drop_keys ist neu, war bei unserer DB nötig!).
    Ich konnte mich zunächst nicht anmelden.
    Die Anmeldung erfolgt nicht wie bei Xentral mit der E-Mailadresse.

    Bei OpenXe ist es: erster Buchstabe vom Vornamen, gefolgt vom Nachnamen.

    Eventuell ist es nötig das, Passwort zurückzusetzen.

    Falls sich kein User mehr einloggen kann, geht es auch wie folgt über die Datenbank:

    In der DB, in der Tabelle user, bei dem betreffenden user, diesen Wert in die Spalte passwordhash eintragen: $2y$10$LfwRpYmGR059mR7tubUb9.NSpUyAkELYCj0aHZLsodV443KqO0qM

    Das Passwort ist dann:

    temp

    Unser Azubi soll das demnächst nochmal nachstellen, falls hier was fehlen sollte trage ich es dann nach.

    Vielen dank an Alex für die Hilfe mit der Datenbank und an alle Beteiligten für OpenXe!

    • Neu

    Alex Bei meinem letzten Versuch des DB-Updates bekomme ich nun auch einen "max key length" Fehler auf der Tabelle 'auftrag' weil er die Spalte shopextid von varchar(255) auf varchar(1024) ändern möchte. Ich verstehe aber derzeit leider nicht woher diese Änderung jetzt plötzlich kommt, die letzten Updates haben das nie ändern wollen. Kannst du da vielleicht schnell helfen?

    Und wieso ist die Spalte shopextid überhaupt so groß? Die längsten mir bekannten Ids von shops sind GUIDs und die sollten ja sogar mit einem varchar(50) klar kommen, oder übersehe ich was?

    • Neu

    Ja, das habe ich auch gesehen, daher habe ich auch nicht verstanden wieso der das plötzlich ändern will und das vorher noch nie wollte.


    Bei -drop_keys will er bei mir alle keys löschen und neu anlegen. Das geht aber wiederum aufgrund von foreign_keys nicht. Aber selbst nachdem er einige entfernt und neu angelegt hat, will er sie beim nächsten run wieder löschen und neu anlegen. Hattest du das schonmal oder liegt das irgendwie an meiner DB?

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden