# Update-Fehler von 6.3.5.4 auf 6.4

**URL:** <https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614>\
**Category:** Shopware 6 (German)\
**Created:** [12. Mai 2021 um 08:17 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614 "2021-05-12T08:17:44Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![WernerBu](https://avatars.discourse-cdn.com/v4/letter/w/71c47a/32.png) [@WernerBu](https://forum.shopware.com/u/WernerBu)\
**Post date:** [12. Mai 2021 um 08:17 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/1 "2021-05-12T08:17:44Z")

</div>

Hallo,

der Update auf 6.4 ist leider bei der Datenbank-Migration hängengeblieben mit dem untenstehenden Fehler, wir hatten die 6.3.5.4 mit PHP 7.4.18 und 10.3.29-MariaDB und der Professional Edition.  
Habe den Fehler hier im Forum bisher nicht gesehen oder hatte den auch jemand gehabt?

Received the following error message:  
An exception occurred while executing ‚ALTER TABLE `product_translation` ADD COLUMN `slot_config` JSON AFTER `custom_fields`, ADD CONSTRAINT `json.product_translation.slot_config` CHECK (JSON\_VALID(`slot_config`))‘: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚`...`.`product.translation`.`custom_fields`‘ in ‚CHECK‘

Please try to fix this error and restart the update.  
Response  
{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE `product_translation`\n ADD COLUMN `slot_config` JSON AFTER `custom_fields`,\n ADD CONSTRAINT `json.product_translation.slot_config` CHECK (JSON\_VALID(`slot_config`))‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚`...`.`product.translation`.`custom_fields`‘ in ‚CHECK‘“}

Danke,  
Werner.

---

<div class="post-metadata">

**Author:** ![blueroger](https://avatars.discourse-cdn.com/v4/letter/b/df788c/32.png) [@blueroger](https://forum.shopware.com/u/blueroger)\
**Post date:** [12. Mai 2021 um 08:35 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/2 "2021-05-12T08:35:15Z")

</div>

Hallo Werner,

> [@Shopware 6.4.0.0 Update Fehler](https://forum.shopware.com/t/shopware-6-4-0-0-update-fehler/87386/8):
>
> Moin zusammen, ich habe auch Probleme mit der 6.4. Version. In meinem Fall, wird das Logo nicht angezeigt obwohl das „Demo Logo“ Bild im Backend eingestellt ist und ich den Block: „layout\_header\_logo“ vom „parent“ nutze. Dazu werden manche Links von einige Pages nicht abgerufen und bekomme die Fehlermeldung " Parameter „Parameter id missing“ is missing.", obwohl ich die ID auch verwende. \<a data-toggle="modal" class="footer-vat ml-3" href="{{ path('frontend.cms.page',{ id: shopware.c…

---

<div class="post-metadata">

**Author:** ![WernerBu](https://avatars.discourse-cdn.com/v4/letter/w/71c47a/32.png) [@WernerBu](https://forum.shopware.com/u/WernerBu)\
**Post date:** [12. Mai 2021 um 13:56 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/3 "2021-05-12T13:56:49Z")

</div>

Okay, beim Recovery-Befehl ausführen, hat es jetzt erstaunlicherweise funktioniert, keine Ahnung warum nicht gleich beim ersten Mal, wir sind jetzt bei Shopware 6.4 😃  
Das Problem war diese Migration: [https://github.com/shopware/platform/blob/trunk/src/Core/Migration/V6\_4/Migration1610337444AddSlotConfigToProductTranslationTable.php](https://github.com/shopware/platform/blob/trunk/src/Core/Migration/V6_4/Migration1610337444AddSlotConfigToProductTranslationTable.php)  
Der SQL-Befehl in der Migration hat auch funktioniert, wenn man den von Hand z.B. in DBeaver ausgeführt hat, hab den dann wieder rückgängig gemacht und den Recovery gestartet. Warum das nicht beim ersten Mal funktioniert hat ist mir schleierhaft.

---

<div class="post-metadata">

**Author:** ![schnere](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/schnere/32/13444_2.png) [@schnere](https://forum.shopware.com/u/schnere)\
**Post date:** [17. Mai 2021 um 10:35 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/4 "2021-05-17T10:35:34Z")

</div>

@WernerBu : Ich hatte dasselbe Problem mit MariaDB 10.3.29.  
Abhilfe schaffte das Downgrade auf MariaDB 10.3.22:

`apt install mariadb-server=1:10.3.22-1ubuntu1`

---

<div class="post-metadata">

**Author:** ![WernerBu](https://avatars.discourse-cdn.com/v4/letter/w/71c47a/32.png) [@WernerBu](https://forum.shopware.com/u/WernerBu)\
**Post date:** [18. Mai 2021 um 05:19 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/5 "2021-05-18T05:19:05Z")

</div>

@schnere Okay, stimmt, habe ich jetzt auch gesehen: „MariaDB 10.3.29, 10.4.19, 10.5.10 are not compatible at the moment“. Frag mich nur, warum [www.dogado.de](http://www.dogado.de) uns diese DB-Version installiert hat, wenn die doch wissen sollten, daß das nicht kompatibel ist.  
Mehr Info von Shopware wäre auch toll, also was denn nun nicht kompatibel ist, soviel kann es ja nicht sein, kann mir beim besten Willen nicht vorstellen, daß von 10.3.22 auf 10.3.29 so ein großer Unterschied bei MariaDB ist, okay, außer die haben in 10.3.29 ein total blöden Bug eingebaut. Und eine Info, ob das dann in naher Zukunft kompatibel gemacht wird, wäre auch nicht schlecht.

Wir sind aber weiterhin mit 10.3.29 unterwegs, der SQL-Befehl in der Migration hat ja letztendlich wie oben beschrieben funktioniert und was anderes ist uns bisher nicht aufgefallen.

---

<div class="post-metadata">

**Author:** ![nkarg1981](https://avatars.discourse-cdn.com/v4/letter/n/df788c/32.png) [@nkarg1981](https://forum.shopware.com/u/nkarg1981)\
**Post date:** [18. Mai 2021 um 06:39 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/6 "2021-05-18T06:39:40Z")

</div>

Hallo , ich habe auch den Fehler - bekomme es aber nicht gelöst. Muss diese Spalte gelöscht werden ? Wenn ja auch das funktionniert nicht. Bräuchte hier Hilfe wie ich da weiter komme.  
Danke schön

## Error

Received the following error message:  
An exception occurred while executing ‚ALTER TABLE `product_translation` ADD COLUMN `slot_config` JSON AFTER `custom_fields`, ADD CONSTRAINT `json.product_translation.slot_config` CHECK (JSON\_VALID(`slot_config`))‘: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚`kmpracing_shopware62021`.`product.translation`.`custom_fields`‘ in ‚CHECK‘

Please try to fix this error and restart the update.

### Response

{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE `product_translation`\n ADD COLUMN `slot_config` JSON AFTER `custom_fields`,\n ADD CONSTRAINT `json.product_translation.slot_config` CHECK (JSON\_VALID(`slot_config`))‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚`kmpracing_shopware62021`.`product.translation`.`custom_fields`‘ in ‚CHECK‘“}

---

<div class="post-metadata">

**Author:** ![WernerBu](https://avatars.discourse-cdn.com/v4/letter/w/71c47a/32.png) [@WernerBu](https://forum.shopware.com/u/WernerBu)\
**Post date:** [18. Mai 2021 um 07:09 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/7 "2021-05-18T07:09:03Z")

</div>

Bei uns hat lustigerweise das Ausführen von /recovery/update dann funktioniert, ein Versuch kann ja nicht schaden.

---

<div class="post-metadata">

**Author:** ![nkarg1981](https://avatars.discourse-cdn.com/v4/letter/n/df788c/32.png) [@nkarg1981](https://forum.shopware.com/u/nkarg1981)\
**Post date:** [18. Mai 2021 um 09:58 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/8 "2021-05-18T09:58:31Z")

</div>

Bei mir leider nicht - gerade versucht  
Läuft auf den gleichen Fehler:

## Error

Received the following error message:  
An exception occurred while executing ‚ALTER TABLE `product_translation` ADD COLUMN `slot_config` JSON AFTER `custom_fields`, ADD CONSTRAINT `json.product_translation.slot_config` CHECK (JSON\_VALID(`slot_config`))‘: SQLSTATE[42S22]: Column not found: 1054 Unknown column ‚`kmpracing_shopware62021`.`product.translation`.`custom_fields`‘ in ‚CHECK‘

Please try to fix this error and restart the update.

### Response

{„valid“:false,„errorMsg“:„An exception occurred while executing ‚ALTER TABLE `product_translation`\n ADD COLUMN `slot_config` JSON AFTER `custom_fields`,\n ADD CONSTRAINT `json.product_translation.slot_config` CHECK (JSON\_VALID(`slot_config`))‘:\n\nSQLSTATE[42S22]: Column not found: 1054 Unknown column ‚`kmpracing_shopware62021`.`product.translation`.`custom_fields`‘ in ‚CHECK‘“}

---

<div class="post-metadata">

**Author:** ![WernerBu](https://avatars.discourse-cdn.com/v4/letter/w/71c47a/32.png) [@WernerBu](https://forum.shopware.com/u/WernerBu)\
**Post date:** [18. Mai 2021 um 12:08 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/9 "2021-05-18T12:08:15Z")

</div>

Oh, tut mir leid.  
Ich hatte den Befehl der Migration ja per Hand in der DB mal ausgeführt, der hatte an sich funktioniert,  
die column hatte ich dann wieder gelöscht und den recovery-Befehl ausgeführt.  
Ansonsten kann ich Dir leider auch nicht weiterhelfen, du hast auch die MariaDB 10.3.29?

@schnere hatte ja ein downgrade vorgeschlagen.  
Allerdings brauchen wir das nicht mehr, da Shopware einen Patch für die 10.3.29 bzw. auch andere Versionen eigentlich schon gemacht hat und irgendwann dann auch einfließt.  
[https://github.com/shopware/platform/commit/eedb9aa47e10295897c38877a687970027d1fc73](https://github.com/shopware/platform/commit/eedb9aa47e10295897c38877a687970027d1fc73)

---

<div class="post-metadata">

**Author:** ![schnere](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/schnere/32/13444_2.png) [@schnere](https://forum.shopware.com/u/schnere)\
**Post date:** [18. Mai 2021 um 12:24 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/10 "2021-05-18T12:24:08Z")

</div>

Also bei mir hat der Befehl manuell tatsächlich auch nicht funktioniert - gleicher Fehler.  
Das Downgrade hat jedenfalls problemlos funktioniert und das ist für mich die praktikabelste Lösung.  
Eine Alternative wäre den Patch zu cherry-picken (was üblicherweise nicht ganz so einfach ist) oder eben auf eine gepatchte Version zu warten.

---

<div class="post-metadata">

**Author:** ![joe\_11](https://avatars.discourse-cdn.com/v4/letter/j/a88e57/32.png) [@joe\_11](https://forum.shopware.com/u/joe_11)\
**Post date:** [19. Mai 2021 um 13:11 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/11 "2021-05-19T13:11:08Z")

</div>

Hallo WernerBU,

kannst du bitte noch mal genau erklären wie du das gemacht hast. Für Anfänger 😉  
„Ich hatte den Befehl der Migration ja per Hand in der DB mal ausgeführt, der hatte an sich funktioniert,  
die column hatte ich dann wieder gelöscht und den recovery-Befehl ausgeführt.“

Danke.

---

<div class="post-metadata">

**Author:** ![enerSpace](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/enerspace/32/13552_2.png) [@enerSpace](https://forum.shopware.com/u/enerSpace)\
**Post date:** [20. Mai 2021 um 12:48 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/12 "2021-05-20T12:48:46Z")

</div>

Falls euer Hoster nicht auf eine ältere MariaDB Version zurück kann oder möchte, gibt es noch die Möglichkeit vor dem Update ein „FLUSH TABLES;“ auszuführen. Das umgeht den Fehler während des Updates. Inwieweit das bei euch auf einem Webpaket angewendet werden kann, sollte euch aber euer Hoster sagen können.

Zum Thema Dogado, da springe ich mal mit ein. In MariaDB gibt es einen Bug. Dieser betrifft die MariaDB Versionen 10.3.29, 10.4.19 und 10.5.10. Meistens werden diese Updates automatisch eingespielt. Ich denke dass die Kollegen vorher nicht wissen konnten, dass es mit der aktuellen MariaDB Version und Shopware 6 zu Problemen kommen könnte. Offensichtlich tritt der Bug auch nicht permanent auf, was die Fehleranalyse erschwert.

Da das Update von Shopware auch früher raus kam als die neue MariaDB Version, gehe ich auch mal davon aus, dass die System-Anforderungen von Shopware nachträglich angepasst wurden.

VG

ener **Space** Webhosting  
Tel.: +49 511 - 999 791 70 | Web: [https://www.enerspace.de](https://www.enerspace.de/)

---

<div class="post-metadata">

**Author:** ![WernerBu](https://avatars.discourse-cdn.com/v4/letter/w/71c47a/32.png) [@WernerBu](https://forum.shopware.com/u/WernerBu)\
**Post date:** [20. Mai 2021 um 14:31 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/13 "2021-05-20T14:31:15Z")

</div>

Hallo,  
an sich habe ich einfach den „Alter Table…“ aus der Migration (s. oben) einfach perHand in phpMyAdmin ausgeführt, dann die Spalte wieder gelöscht und die update/recovery-Seite aufgerufen. Aber so wie es aussieht, hat das wohl nur zufällig bei uns funktioniert.  
Denke, der Hinweis von enerSpace ist der richtigere.

---

<div class="post-metadata">

**Author:** ![vismagine](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/vismagine/32/24302_2.png) [@vismagine](https://forum.shopware.com/u/vismagine)\
**Post date:** [14. Juni 2021 um 10:29 UTC](https://forum.shopware.com/t/update-fehler-von-6-3-5-4-auf-6-4/87614/14 "2021-06-14T10:29:45Z")

</div>

Danke für die hilfreichen Hinweise, insbesondere der Hinweis mit bzgl. „FLUSH TABLES“ hat geholfen. Da uns die Rechte dazu fehlten, haben wir beim Provider angerufen, welcher den Befehl in der MariaDB 10.5.10 für uns ausführen konnte.

Wir hatten danach noch Probleme den „Wartungs-Modus“ auszuschlaten. Letztlich hat es mit den erneuten Aufruf von `/recovery/update/index.php/cleanup` funktioniert.
