kann jemand in dem Zusammenhang mit dem folgenden Fehler bei einem Update auf 6.4.3.0 helfen?
Danke und viele Grüße,
Oliver
Error
Received the following error message:
An exception occurred while executing 'ALTER TABLE order DROP FOREIGN KEY fk.order.created_by_id': SQLSTATE[42000]: Syntax error or access violation: 1091 Can’t DROP FOREIGN KEY fk.order.created_by_id; check that it exists
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„An exception occurred while executing 'ALTER TABLE order DROP FOREIGN KEY fk.order.created_by_id':\n\nSQLSTATE[42000]: Syntax error or access violation: 1091 Can’t DROP FOREIGN KEY fk.order.created_by_id; check that it exists“}
Moin moin,
ich sehe ich bin nicht allein, habe gerade das selbe Szenario vor mir.
Mein Update sollrte mich von v6.4.2.1 auf v6.4.4.1 bringen, leider mit selbem Fehler.
Auch hier ist schon ein Beitrag dazu, leider auch noch offen.
Hat sich zu dem Thema schon etwas herausfinden lassen?
leider kein Feedback zu dem Problem. Wir haben alles in einer Nachtaktion neu aufgesetzt. Das war einfacher als ursprünglich gedacht; wir standen aber auch ganz am Anfang eines Projekts.
Den Fehler da hatte ich auch mal und habe den gelöst in dem ich in der Migrationsdatei irgendwo das SQL Statement rausgenommen habe wo an dem Fremdschlüssel rumgefrickelt wird.
Man kann praktisch keine Updates mehr machen ohne diese vorher mal gestetest zu haben. (Live System Backuppen → Stage System deployen → Update testen → wenn OK auf dem Live System)
Ich entwickle Software seit vielen Jahren (nicht PHP), mir ist es bis heute nicht gelungen ein SW Update in 1h durchzuführen und ohne irgendwelche manuellen Eingriffe vornehmen zu müssen. Seien es nicht-gebaute JS/CSS bundels oder Fixes für Migrationen. Es ist für Laien praktisch unmöglich SW Updates durchzuführen. Wenn das Update mal im Wartungsmodus hängen bleibt, hat ein Laie keine Möglichkeit irgendwas sinnvolles zu tun außer sich Hilfe zu holen.
Hi Olli,
Respekt ist immer gut
… den sollte man einer kostenlos bereitgestellten Open Source Software immer entgegenbringen, denn da läuft nie alles glatt.
BG Jan
Schön dass du es erwähnst, genauso ists richtig und sollte beherzigt werden.
Ich selber habe auf meinen Systemen zudem eine praktische Backup Funktion die mir per Knopfdruck eine DB und/oder ein Filesystem Backup erzeugt. So ist ein einfaches Rollback unkompliziert innerhalb von wenigen Minuten immer möglich. Kann das nur jedem ans Herzlegen, denn es spart im Fall des Fehles immens Zeit
…dem Ansatz hier werd ich mal nachgehen, vielleicht bringt er mich auch ans Ziel, Danke Dir
Ursache des ganzen war das ich einen unbekannten abgebrochenen Update Versuch zuvor im System hatte und dadurch die Tabellen bereits neu waren. Mit dem dann Folgenden Updateversuch lief das System dann immer in den obigen Fehler.
Vielleicht hilf es ja noch einmal jemandem weiter.
Hatte nahezu selbiges Problem und dieser Thread hier half mir bei der Lösung:
Migration von 6.3.4.1 auf 6.4.20.1
Ausführen von vendor/shopware/recovery/Update/index.php brach ab mit Can’t DROP FOREIGN KEY fk.order_tag.tag_id
Manuell per phpmadmin den fk.order_tag.tag_id gelöscht.
Unter ./vendor/shopware/core/Migration/V6_4/Migration1642517958AddCascadeDeleteToTagRelations.php die Zeile #24 auskommentiert:
#$connection->executeStatement(‚ALTER TABLE order_tag DROP FOREIGN KEY fk.order_tag.tag_id;‘);
Übrigens habe ich festgestellt, dass das Statement auch nicht in phpmyadmin läuft und mit dem selben Fehler wir das recovery script abbricht. Benenne ich allerdings das Feld mal aus dumdiedeldei-so-blöd-kannst-du-net-denken um in fk_order_tag_tag_id (also Underscores statt Dots ) dann funktioniert das Statement in phpmyadmin. Vielleicht sollte man grundsätzlich keine Punkte in Schlüsselnamen verwenden?
