In meinem Falle MySQL 5.7.27
Mahlzeit,
habe leider eine ähnliche Meldung bekommen:
An exception occurred while executing 'ALTER TABLE product DROP FOREIGN KEY fk.product.cms_page_id': SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚DBNAMEN.product_review.product.category_tree‘ in ‚CHECK‘
Gibt es da evt schon Abhilfe?
Gruß Helle
Ok, hab den Fehler selber gefunden…hatte auf die neusten MariaDB Version geupdated…mit der passenden Version gehts dann auch.
Gruß Helle
… auch hier endlich den nervigen Fehler gefunden.
In der Tabelle „cms_page_translation“ waren zwei Templates – und hier hat es den Anschein, dass diese Templates aus der/m Shopdemo/Plugin erstellt worden sind – die keinen Bezug zur Tabelle „cms_page“ genriert hatten.
Diese beiden Templates mussten aus der Tabelle „cms_page_translation“ gelöscht werden. Und
nach mehreren Anläufen hat das Update dann auch geklappt. Nur warum das nicht ad hoc geklappt hat, bleibt wohl ein Geheimnis.
Gibt es für den ursprünglichen Fehler schon eine Lösung seitens Shopware? Wir hängen nun seit 1 Woche mit unserem (zum Glück noch Test-Shop) im Limbo.
Hallo zusammen,
ich kämpfe auch am gleichen Problem, bei mir funktioniert das Update weder auf einer:
Version MySQL: 5.7.33-0ubuntu0.18.04.1 mit PHP-Erweiterung MySQLi
noch
Server-Version: 10.3.23-MariaDB-1:10.3.23
Ein Update direkt von v6.3.5.2 auf 6.4 führt zum Fehler.
Ein Update von v6.3.5.2 auf die Version 6.3.5.4 und dann auch 6.4 führt zum gleichen Error.
> *Error*
> *Received the following error message:*
> *An exception occurred while executing 'ALTER TABLE `cms_slot` ADD CONSTRAINT `fk.cms_slot.cms_block_id` FOREIGN KEY (`cms_block_id`, `cms_block_version_id`) REFERENCES `cms_block` (`id`, `version_id`) ON DELETE CASCADE ON UPDATE CASCADE': SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`c1testDB`.`#sql-41ea_4b7d6f`, CONSTRAINT `fk.cms_slot.cms_block_id` FOREIGN KEY (`cms_block_id`, `cms_block_version_id`) REFERENCES `cms_block` (`id`, `version_id`) ON DELETE CASCADE ON UP...)*
Hat jemand bereits einen Ansatz gefunden? Wird Shopware da etwas liefern, habt Ihr das auf dem Radar?
Mein naiver Ansatz die Rows für die keine cms blöcke existieren aus der cms_slot Tabelle zu löschen führte zu dem folgenden Fehler:
*## Error*
*Received the following error message:*
*Tables with multi column primary keys not supported*
*Please try to fix this error and restart the update.*
*### Response*
*{"valid":false,"errorMsg":"Tables with multi column primary keys not supported"}*
So habe ich nach den rows gesucht.
SELECT * FROM cms_slotas s LEFT JOINcms_block as b on s.cms_block_id = b.id WHERE b.id IS NULL
Beim Debuggen habe ich herausgefunden das die methode: createModifyPrimaryKeyQuery() vom MakeVersionableMigrationHelper welcher von der Migration Migration1612851765MakeCmsVersionable ausgeführt wird ein Problem damit hat, dass die Tabelle cms_page zwei indizes aktuell führt: Indizes PRIMARY id , version_id jedoch nur 1 Index zulässig ist.
$pk = $this->schemaManager->listTableIndexes($tableName)['primary'];
if (\count($pk->getColumns()) !== 1) {
throw new \RuntimeException('Tables with multi column primary keys not supported');
}
Würde mich über Tipps oder mögliche Lösungsansätze freuen.
Gruß Sergej
Kurzer Nachtrag.
Nachdem ich nun den primary key check entfernt habe und die version_id der Tabellen die im Bild markiert sind gelöscht habe (der Updater hat hier auch mit Fehlern um sich geworfen), konnte ich das Update durchführen.
ACHTUNG: das Löschen der version_id ist ein fehler von mir! Das ist nur der Fall wenn nach einem oben unterbrochenen Update auf die bereits modifizierte DB ein Update gemacht wird!
Hallo,
bei uns leider sehr selbe Fehler wie AMSPO24online
Wir nutzen MySQL: 5.7.34-1 mit PHP-Erweiterung MySQLi
Gibt es mittlerweile Infos was den Fehler verursacht bzw. ob oder wie er behoben werden kann? Die Aussage von Moritz_Naczenski, dass Shopware sich das anschaut ist ja nun auch schon über zwei Wochen her und anscheinend gibt es ja einige die diesen Fehler bekommen.
Grüße
Christian
Grundsätzlich sollte ja jeder ein Backup einspielen, wenn es während des Updates zu einem Fehler kommt. Für dieses konkrete Problem wird es mit dem nächsten Update auch einen fix geben und dann könnt ihr das Update nochmal versuchen.
Die Updates kommen ja regulär immer zum Anfang des Monats, in diesem Fall dann Anfang Juni.
OK, man sichert definitv, aber dieses Mal klappt - zumindest bei mir - das Einspielen der gesicherten Datenbank nicht - es kann nur die „neue“ der 6.4 wieder eingespielt werden, die 6.3er führt jetzt nach diesem Update zum Fehler 1215 Fremdschlüsselbeschränkung usw… muss hoffen, dass mein Hoster mir eine Lösung zeigt, sonst war’s das wohl…
Ich habe schon an Lösungen gearbeitet, wo ein Datenbank-Schema Update dynamisch erzeugt wird. Es wird aus einem Schema-Template und dem aktuellen Schema ein Delta erzeugt und anschließend auch nur die Stellen aktualisiert, die Relevant sind. Wieso wäre dies in Shopware eigentlich nicht möglich? Ich kenne Shopware seit Anfang der 5er Version und genau an diesen Stellen hat Shopware schon immer geschwächelt. Eigentlich sind doch alle Infos in den EntityDefinitions vorhanden und Shopware 6 basiert doch zu 100% auf diese EntityDefinitions.
Ich werde dieses Thema wahrscheinlich für meine Plugins verfolgen - die aktuelle technische Umsetzung (Auch mit der Migration-Tabelle) halte ich für sehr anfällig und zeitraubend.
1 „Gefällt mir“
Hallo in die Runde, hat schon jemand erfolgreich mit 6.4.1.0 den Update-Versuch gewagt? Ist der Fehler behoben?
Unser Update von 6.4.0 auf 6.4.1 lief gestern fehlerfrei durch. Aber auch nur weil ich vorher die Datenbank-Struktur von Hand repariert habe, sodass sie der Struktur einer separaten Testinstallation ohne Plugins und Produkten glich. Dabei musste ich auch eine Handvoll Datensätze aus verschiedenen Tabellen löschen, damit foreign keys erfolgreich angelegt werden konnten.
Da diese „cannot add or update a child row“ Fehler eben auf Datensätze hinweisen die man löschen müsste, glaube ich auch nicht dass irgendein zukünftiges Update dies eigenständig macht.
Oh Gott, heißt das, dass man SQL-Profi sein muss, um dieses Update doch mal zu machen??? Dann hab ich ziemlich schlechte Karten…
Hallo, wir haben auch Probleme mit dem Update. Auch wir bekommen die Meldung. Wird das 6.4 Package auch noch einmal aktualisiert, oder müssen wir dann direkt auf 6.4.1 gehen?
Wir sind bei Timmehosting mit den hinterlegten Shopware6 Einstellungen… Vielleicht noch jemand?
Received the following error message:
Tables with multi column primary keys not supported
Please try to fix this error and restart the update.
### Response
{"valid":false,"errorMsg":"Tables with multi column primary keys not supported"}
Moin moin, ja, besser ist es Profi zu sein und nicht nur bei SQL 
.
Ich gehe einen Schritt zurück, da die Ansprüche zu hoch sind. Das läuft mit meinem Hosting nicht so gut. Auch mein Ranking liegt bei ca. 7%.
Ich denke, dass man einen leistungsstarken Server braucht.
Und am Rande, läuft 6.4.0.x nicht.
Hallo,
es geht ja nicht darum, dass jeder ein Backup hat (sollte selbstverständlich sein). Wir haben es erstmal in einer Stagingumgebung getestet da ja bekannt ist, dass es zu Fehlern kommen kann.
Wir nutzen MySQL: 5.7.34-1 mit PHP-Erweiterung MySQLi Alle Plugins und Themes wurden deaktiviert.
Leider wurde der Fehler bei dem neuen Update (6.4.1.0) nicht behoben. Es kommen beim Update ständig Datenbankfehler. Wenn man diese versucht händisch zu beseitigen kommt dann irgendwann, der Fehler „multi column primary keys not supported“. Da weiß ich leider nicht weiter. Vielleicht kann dazu jemand einen Tipp geben - bitte für doofe, die nicht viel Ahnung von SQL haben.
Der Fehler kommt wohl dann, wenn man die Migration zweimal versucht zu starten, ohne das System nach dem ersten fehlerhaften Versuch auf das ursprüngliche zurückzusetzen (also den Backup erst einspielen, dann neuer Versuch). Sie auch diesen Beitrag dazu https://forum.shopware.com/t/shopware-6-4-0-update-error/87365/55
Ich hatte auch den Fehler „sms_slot“ (und nicht wie auch oft besprochen „cms_page_translation“) und habe ihn mit folgendem SQL-kommando wegbekommen:
select * from cms_slot where cms_block_id not in (select id from cms_block);
delete from cms_slot where cms_block_id not in (select id from cms_block);
Wichtig ist, dass man ihn vor dem Update ausführt - ansonsten kommt es zu dem „multi column primary keys not supported“ - Fehler.
1 „Gefällt mir“