Ich habe angefangen die tabellen zu löschen, die laut script schon existieren.
Zum Einen hat man das gefühl man dreht sich im kreis… da man gefühlte fünf mal die gleichen tabellen löscht um dann folgendes zu erhalten:
Error
Received the following error message:
Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚plugin_id‘ in ‚field list‘
in der app.php finde ich auch kein debug, wie im link erläutert und eine Spalte error_msg in der Tabelle s _schema_version finde ich auch nicht…
Hallo,
genau das Gleiche bei mir. Update erzeugte die Tabellen, um dann den Fehler auszugeben. Das kannst du unendlich lang machen. Update auf 5.2 ist somit nicht möglich.
Ich frage mich, ob jemand das Update geschafft hat ohne diese Probleme. Scheint hier im Forum dazu noch keine Lösung zureisen.
Ich versuche von 5.2.0 BETA1 auf 5.2.1 zu aktualisieren. Bekomme allerdings einen ähnlichen Fehler:
Error
Received the following error message:
Could not apply migration: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‚title‘
Please try to fix this error and restart the update.
Response
{„valid“:false,„errorMsg“:„Could not apply migration: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‚title‘“}
ich habe leider auch das Problem mit dem Update von 5.2 Beta zu 5.2.1, löscht man den Eintrag in der Datenbank kommt ein neuer Hinweis es ist ein Fass ohne Boden.
Da es sich ja bei mir nur um ein Testshop handelt, in dem ich Änderungen und meine Plugin teste, werde ich diesen neu aufsetzen.
habe genau das gleiche Problem vom Update von 5.1.6 auf 5.2.9
“valid”:false,“errorMsg”:"Could not apply migration (Migrations_Migration708). Error: SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘s_filter_values_attributes’ already exists "}
Ich erhalte ebenfalls die Hinweise, dass die Tabellen bereits existieren. Das löschen aller oben angegebenen Tabellen habe ich ebenfalls versucht und habe dann die Domain:
Could not apply migration (Migrations_Migration709). Error: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‘default_shipping_address_id’
Please try to fix this error and restart the update.
Response
{"valid":false,"errorMsg":"Could not apply migration (Migrations\_Migration709). Error: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name 'default\_shipping\_address\_id' "}
"
Das war schon der zweite Versucht nach einem Backup.
Ich brauche auch Hilfe von jemanden, der für mich das Update durchführen kann.
danke für den Link. Ich hatte das BackUp von Domainfactory einspielen lassen. Jetzt hab ich aber das Problem, dass selbst bei meiner funktionierenden Version Tabellen in der Datenbank vorhanden sind, die erst mit dem Update kommen, da wir bereits zwei mal ein BackUp haben einspielen lassen.
Was kann ich denn nun machen ? Gibt es eine Drop-Table Anweisung für alle betroffenen Tabellen, die nach dem Update 5.1.6 hinzukommen, damit ich diese manuell in der DB löschen kann? Es handelt sich um das Live-System.
Ich habe dasselbe Problem! Die Tabelle s_filter_values_attributes wird vom Updater immer wieder neu angelegt, nachdem sie manuell gelöscht wurde. Danach kommt sofort wieder die Fehlermeldung.
Daher nochmal die Frage: Welche Tabellen wurden in 5.2 hinzugefügt? Offenbar haben wir hier eine Datenbank die unter 5.1 läuft, wo aber vorher schon mal ein Update auf 5.2 versucht wurde, da sind jetzt lauter leere Tabellen drin (ich tippe auf die Freitextfelder).
Diese Tabellen müssen vor Start des Updaters manuell gelöscht werden, sonst bleibt der Ablauf hängen.
Gibt es vielleicht trotzdem eine Hilfestellung wie das Problem zu lösen ist?
Es gibt sicher nicht wenige User die beim Update von 5.1.6 auf 5.2.x wieder ein Backup hatten einspielen müssen, weil nach dem Update der Shop nicht mehr zu gebrauchen war.
das alleine hilft dir ja nicht. Es gibt teilweise große Migrationen in der Datenbank. Da musst du dich also wirklich sonst Stück für Stück durcharbeiten
Es gibt ja eine Migration, die immer fehlschlägt. Genau diese muss man dann manuell korrigieren. Dann in der Tabelle s_schema_version diese Migration als erledigt markieren und das Update wieder ausführen
Wenn ich unter shopware/_sql/migrations at 5.2 · shopware/shopware · GitHub nachsehe, dann ist das der letzte Eintrag, bevor es mit 700 weitergeht. Bin auch total verwundert, warum angeblich schon Veränderungen in der Datenbank vorhanden sein sollen. Das Datum des letzten Eintrags in s_schema_version ist von Mai, SW 5.2 ist aber erst im Juli erschienen. Das passt rigendwie nicht richtig zusammen…
Und nu? Was muss ich tun, damit der Updater für 5.2 fehlerfrei durchläuft?
Alles klar, der Tipp hat bei mir jetzt funktioniert, vielen Dank! Nach Ausführen von
SET FOREIGN_KEY_CHECKS=0;
DROP TABLE s_filter_values_attributes;
DROP TABLE s_filter_options_attributes;
DROP TABLE s_product_streams_attributes;
DROP TABLE s_attribute_configuration
DROP TABLE s_user_addresses;
DROP TABLE s_user_addresses_attributes;
SET FOREIGN_KEY_CHECKS=1;
in phpMyAdmin ist das Update einwandfrei durchgelaufen.
