Syntax error or access violation: Specified key was too long; max key length is 767

**intradesign** · 01.01.2019, 19:25

Moin zusammen und frohes neues!!

Ich bin (wieder mal) am verzweifeln, weil Contao weder bei einer Neuinstallation noch bei einem Update funktioniert. Das Problem tritt bei mehreren Servern auf. Die Installation per Contao Manager läuft korrekt ab, im Install-Tool erscheint nach Klicken auf Aktualisierung der Datenbank die Contao-Fehler-Seite und im Protokoll steht folgender Fehler:

[2019-01-01 18:57:26] request.CRITICAL: Uncaught PHP Exception Doctrine\DBAL\Exception\DriverException: "An exception occurred while executing 'CREATE TABLE tl_newsletter_recipients (id INT UNSIGNED AUTO_INCREMENT NOT NULL, pid INT UNSIGNED DEFAULT 0 NOT NULL, tstamp INT UNSIGNED DEFAULT 0 NOT NULL, email VARCHAR(255) DEFAULT '' NOT NULL, active CHAR(1) DEFAULT '' NOT NULL, addedOn VARCHAR(10) DEFAULT '' NOT NULL, confirmed VARCHAR(10) DEFAULT '' NOT NULL, ip VARCHAR(64) DEFAULT '' NOT NULL, token VARCHAR(32) DEFAULT '' NOT NULL, UNIQUE INDEX pid_email (pid, email), INDEX email (email(191)), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT = DYNAMIC': SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes" at /var/www/vhosts/domain.tld/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php line 106 {"exception":"[object] (Doctrine\\DBAL\\Exception\\DriverException(code: 0): An exception occurred while executing 'CREATE TABLE tl_newsletter_recipients (id INT UNSIGNED AUTO_INCREMENT NOT NULL, pid INT UNSIGNED DEFAULT 0 NOT NULL, tstamp INT UNSIGNED DEFAULT 0 NOT NULL, email VARCHAR(255) DEFAULT '' NOT NULL, active CHAR(1) DEFAULT '' NOT NULL, addedOn VARCHAR(10) DEFAULT '' NOT NULL, confirmed VARCHAR(10) DEFAULT '' NOT NULL, ip VARCHAR(64) DEFAULT '' NOT NULL, token VARCHAR(32) DEFAULT '' NOT NULL, UNIQUE INDEX pid_email (pid, email), INDEX email (email(191)), PRIMARY KEY(id)) DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci ENGINE = InnoDB ROW_FORMAT = DYNAMIC':\n\nSQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes at /var/www/vhosts/domain.tld/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:106, Doctrine\\DBAL\\Driver\\PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes at /var/www/vhosts/domain.tld/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:90, PDOException(code: 42000): SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 767 bytes at /var/www/vhosts/domain.tld/httpdocs/vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/PDOConnection.php:88)"} []

In allen Fällen sind mir im Contao-Manager folgende Anweisungen aufgefallen:

Spalten ändern

Code:

DROP INDEX path ON tl_files
DROP INDEX email ON tl_member
DROP INDEX fromtable ON tl_version

Spalten anlegen

Code:

CREATE INDEX path ON tl_files (path(191))
CREATE INDEX email ON tl_member (email(191))
CREATE INDEX fromtable ON tl_version (fromtable(191))

Wenn ich die oberen Anweisungen im PHP-MyAdmin manuell ausführe, werden sie vom Contao-Install-Tool rückgängig gemacht und es erscheinen wieder alle 6 SQL-Anweisungen. Bei den unteren drei Anweisungen erscheint die SQL-Fehlermeldung Syntax error or access violation: Specified key was too long; max key length is 767

Zwei der getesteten Systeme sind eigene Server auf CentOS 7-Basis, auf denen alles bisher einwandfrei funktioniert hat (wobei "bisher" relativ ist, da gefühlt bei JEDEM Update im letzten Jahr immer irgendwas nicht funktionierte und viel Zeit für die Fehlersuche und -Bereinigung draufging, aber zumindest haben vor Weihnachten Installationen und Updates fehlerfrei funktioniert). Der Dritte Server ist ein Ubuntu-Server.

Ich bin inzwischen echt angenervt von den immer wieder auftretenden Problemen. Warum passiert das immer wieder?

Hat jemand eine Idee, wo genau das Problem in diesem Fall liegt?

Vielen Dank und viele Grüße,
Timo

**neelix** · 01.01.2019, 19:35

Möglicherweise die gleiche Ursache wie hier:
https://community.contao.org/de/show...-key-name-quot

Ich bin inzwischen echt angenervt von den immer wieder auftretenden Problemen. Warum passiert das immer wieder?

Mir kam auch gerade der Eindruck, dass Contao sich mit dem Wechsel zum Synphonie-Framework keinen Gefallen getan hat. Es kommen immer mehr Abhängigkeiten von Drittanbietern dazu und ein kleiner Fehler oder Änderung dort wirkt sich sofort an zig Stellen aus.

***xchs*** · 01.01.2019, 19:39

Könntest Du vielleicht noch die Versionsangaben zur Contao-Installation und Doctrine DBAL liefern?

**Toubibe** · 01.01.2019, 21:55

Ich gehe davon aus, dass Du Contao 4.6 installiert hast, denn dort hatte ich dasselbe Problem aktuell. Offenbar liegt nach wie vor ein Problem mit doctrine/dbal vor.

Also wenn ich die Diskussion im Forum und die Einträge unter anderem von Leo im Github betrachte, scheint das Problem mit doctrine/dbal und Contao 4.6 weiterzubestehen, während das Problem für die Version 4.4 gelöst zu sein scheint.
Siehe dazu Github https://github.com/contao/contao/issues/238 --> offenbar wurden in Contao 4.6.12 die notwendigen Kompatibilitätsänderungen durchgeführt, aber nach wie vor besteht wenn ich das ganze richtig verstanden habe ich Bug in doctrine/dbal (Leo: Note that Doctrine still needs to fix doctrine/dbal#3414 so index length changes are detected correctly).

Ich denke, im Moment gibt es nur den Weg, dass in der composer.json die dbal Version 2.9 als Konflikt aufgeführt wird:
"conflict": {
"doctrine/dbal": "^2.9"
},
Dadurch wird dbal 2.8.1 verwendet und damit läuft das ganze wieder korrekt, allerdings wird gleichzeitig auf die Contao-Version 4.6.11 runtergestuft - aber immerhin läuft es so. NIcht jedoch bei meinen Versuchen weder mit dbal 2.9.1 noch mit 2.9.2.
Und der Versuch, die Contao-Version 4.6.12 durch einen entsprechenden Eintrag in der composer.json zu "erzwingen" unter oben eingetragenem Konflikt (also unter dbal 2.8.1), ergibt die Fehlermeldung im Contao-Manager: "Console task terminated" ... "- contao/installation-bundle 4.6.12 requires doctrine/dbal ^2.9 -> satisfiable by doctrine/dbal[v2.9.0, v2.9.1, v2.9.2]"

Kurz: bei mir läuft es nur mit dbal 2.8.1 und Contao 4.6.11 und jetzt warte ich auf Doctrine, dass die ihre Hausaufgaben machen ;-) Wenn ich dort richtig interpretiert habe, ist dies als Milestone für dbal 2.10 notiert.

**intradesign** · 02.01.2019, 09:41

Ja, genau. Ich habe den Contao Manager in der neuesten Version heruntergeladen und Contao in der neuesten Version installiert.

Beim Update-Versuch war es von Version 4.6.9 auf 4.6.12.

Die anderen Komponenten sind alle durch die Installation bzw. das Update vorgegebenen Versionen.

**PaddySD** · 02.01.2019, 09:44

@Moderation
Wäre es nicht geschickter, dass in einem Thread zusammen zu führen?

https://community.contao.org/de/show...-key-name-quot

**3dr** · 09.01.2019, 11:25

Ich bin heute (09.01.2019) in den Fehler gerannt beim Update von Version 4.6.5 auf 4.6.12 bei all-inkl.com, MySQL-Version 5.6.38, PHP 7.1. Der folgende Eintrag in der composer.json

Code:

"conflict": {
	"doctrine/dbal": "^2.9"
	},

brachte alles wieder zum Laufen, allerdings verbunden mit einem Downgrade auf 4.6.11

So ärgerlich dieser Fehler ist, ich kann alle erforderlichen Maßnahmen sehr komfortabel über den Contao-Manager abwickeln. Dieses Tool finde ich einfach großartig, für mich als Designer und Nichtentwickler ist es gerade bei den jetzt so häufigen Änderungen für den Betrieb von Contao unverzichtbar geworden, danke dafür!

***xchs*** · 09.01.2019, 11:27

Das solltest Du besser auf

Code:

"doctrine/dbal": "2.9.1 || 2.9.2"

ändern.

**3dr** · 09.01.2019, 11:52

Okay, danke dir, wo ist denn da der Unterschied zum Eintrag

Code:

"conflict": {
		"doctrine/dbal": "2.9.1|2.9.2"
	},

denn der hat nicht funktioniert

Code:

"conflict": {
		"doctrine/dbal": "2.9.1 || 2.9.2"
	},

bedeutet das nicht: 2.9.1 oder 2.9.2 nicht verwenden wegen eines Konflikts mit anderen Ahängigkeiten?

***xchs*** · 09.01.2019, 16:49

Zitat von 3dr

denn der hat nicht funktioniert

Was genau hat denn nicht funktioniert?

Zitat von 3dr

bedeutet das nicht: 2.9.1 oder 2.9.2 nicht verwenden

Ja, genau. Beide Einträge sind soweit gleichwertig.

**3dr** · 09.01.2019, 16:53

Was genau hat denn nicht funktioniert?

Das Install-Tool lief nicht durch wie hier beschrieben

***xchs*** · 09.01.2019, 17:04

Du hast im Contao Manager eine vollständige (!) Paketaktualisierung ausgeführt?
Lösche ggf. Deine composer.lock (oder benenne sie um) und lass anschließend die Paketabhängigkeiten neu auflösen (ebenfalls via CM und "Pakete aktualisieren")

**3dr** · 09.01.2019, 17:45

Du hast im Contao Manager eine vollständige (!) Paketaktualisierung ausgeführt?

Möglicherweise nicht, ich habe diesen Eintrag in der composer.json vorgenommen:

Code:

"conflict": {
		"doctrine/dbal": "2.9.1 || 2.9.2"
	},

und danach im Manager nochmals eine vollständige Paketaktualisierung durchgeführt, dann funktionierte alles. Die composer.lock musste ich nicht anfassen.