Neu Datenbankmigration "General error: 1709 Index column size too large. The maximum column size is 767 bytes" nach Update von 5.2.4 auf 5.3.3.

HelmaSpona

Sehr aktives Mitglied
7. Dezember 2012
791
34
Kerken
Bei dem Versuch die DAtenbankmigration zu machen, kommt eine FEhlermeldung nach der anderen: Die da lauten: "General error: 1709 Index column size too large. The maximum column size is 767 bytes" in: /var/www/vhosts/XXX/httpdocs/update/migrations/20221014132527_create_index_for_newsletter.php"

Was ist zu tun? Ich habe vorher alle Plug-Ins deaktiviert, nachgesehen, ob es vorher schon irgenwelche Problemzonen gab und ALLE behoben. und dennoch geht das Update nicht? So langsam frage ich mich, ob es nicht sogar sinnvoll ist wenn man sich dank der Preispolitik von JTL umorientiert ...

Das 5. Shop-Update in dieser Woche, 1 davon ging reibungslos, eines fast reibungslos, eines eine Vollkatastrophe und jetzt dieses hier. ... Also die Problemquote liegt bei 75%.
 

HelmaSpona

Sehr aktives Mitglied
7. Dezember 2012
791
34
Kerken
Hier scheint etwas mit der SHop Datenbank nicht ganz zu stimmen, ggfls. muss da der Hoster schauen.

Aber evtl. hilft das hier :

https://forum.jtl-software.de/threads/fehler-beim-update-von-5-2-2-auf-5-2-3.209617/
Also auf dem Server läuft MariaDB in einer Version, die lt. JTL-Doku in Ordnung ist. vorher war PHP 8.1.29 aktiv, jetzt habe ich es auch mit PHP 8.2.2 probiert. geht ebenso nicht.

Ich denke schon drüber nach, mit einer neuen DB anzufangen. kann man die Kundendaten aus der WAWI wieder in den Shop übertragen? Das wäre das einzige, was sonst ärgerlich wäre, wenn die Kunden sich neue Kundenkonten anschaffen müssten.
 

NoOne

Sehr aktives Mitglied
16. März 2024
314
106
Also auf dem Server läuft MariaDB in einer Version, die lt. JTL-Doku in Ordnung ist. vorher war PHP 8.1.29 aktiv, jetzt habe ich es auch mit PHP 8.2.2 probiert. geht ebenso nicht.

Ich denke schon drüber nach, mit einer neuen DB anzufangen. kann man die Kundendaten aus der WAWI wieder in den Shop übertragen? Das wäre das einzige, was sonst ärgerlich wäre, wenn die Kunden sich neue Kundenkonten anschaffen müssten.
Eine neue DB nutzt dir auch nichts, wenn die genauso konfiguriert ist. Entweder muss hier das ROW_FORMAT der Tables auf Dynamic gesetzt werden oder, falls das schon der Fall ist, innodb_large_prefix auf true. Die MariaDB-Version ist das eine, die Konfiguration von MariaDB das andere. Der Hoster kann ggf. helfen. Ansonsten ServicePartner oder ggf. Ticket bei JTL. Wobei das eher ein Datenbank-Thema ist und kein Shop-Thema.
 
  • Gefällt mir
Reaktionen: HelmaSpona

HelmaSpona

Sehr aktives Mitglied
7. Dezember 2012
791
34
Kerken
Eine neue DB nutzt dir auch nichts, wenn die genauso konfiguriert ist. Entweder muss hier das ROW_FORMAT der Tables auf Dynamic gesetzt werden oder, falls das schon der Fall ist, innodb_large_prefix auf true. Die MariaDB-Version ist das eine, die Konfiguration von MariaDB das andere. Der Hoster kann ggf. helfen. Ansonsten ServicePartner oder ggf. Ticket bei JTL. Wobei das eher ein Datenbank-Thema ist und kein Shop-Thema.
Danke, dann gucke ich mir noch mal an, ob ich was davon umsetzen kann. Der Hoster ist absolut nicht hilfreich :(
 

zentiva

Aktives Mitglied
18. März 2014
36
2
Viersen
Firma
eSales4u
Die gleiche Fehlermeldung auch bei uns...

Die Lösung war:
in der toptin-Tabelle war das Feld cMail als varchar(256) angelegt. Das war wohl zu lang für UTF8. Im phpMyAdmin das Feld auf varchar(255) gesetzt.

Bei der Gelegenheit war noch aufgefallen, dass 3 Tabellen mit utf8mb4_unicode_ci angelegt waren:

tlieferadressevorlage
teinstellungenlog
teinstellungen_default

die wurden auch gleich noch umgestellt auf utf8_unicode_ci

Danach lief das Datenbank-Update wieder problemlos weiter und ohne weitere Fehler komplett durch.:D

Vielen Dank an den Hoster ZitroHosting, der uns hier prima unterstützt hat! :thumbsup::thumbsup: