Installation 3.5.15.Tabellen überprüfen

[manoelo]

Nach der Installation von Contao bekomme ich folgend Meldung
was bedeutet das
grUß manoelo

Tabellen prüfen

Die Datenbank ist nicht aktuell!

Beachten Sie, dass der Update-Assistent bisher nur mit MySQL- und MySQLi-Treibern getestet wurde. Wenn Sie eine andere Datenbank verwenden (z.B. Oracle), müssen Sie die Datenbank ggf. manuell installieren bzw. aktualisieren.
Bestehende Spalten ändern
Alle auswählen


ALTER TABLE `tl_files` DROP INDEX `path`, ADD KEY `path` (`path`(333));

[Andreas]

Eine Optimierung für die Tabelle tl_files. Die Indexierung wurde geändert. Das solltest du ausführen. Die Tabelle, Spalten oder Werte werden dabei nicht angefasst.

[manoelo]

Ja schon wollt ich ja tun,
aber wenn ich es ausführe passiert nichts Tabelle bzw Datenbank lässt sich nicht aktualisieren
schöne Grüße Manoelo

[tab]

Und das war eine komplette Neuinstallation aus dem Downloadarchiv von 3.5.15? Und die Datenbank war vor der Installation leer, also alle enthaltenen Tabellen gelöscht?

[manoelo]

ja

[Andreas]

MySQLi Treiber ausgewählt? Contao-Check ausgeführt um zu sehen, ob die PHP-Version und die MySQL-Version passen? (bin mir grad nicht sicher, ob auch die MySQL-Version gecheckt wird). Mit dem Check-Tool validiert?

[manoelo]

Mysqli >hab ich
php version ist 5.6

[manoelo]

hab nochmal alles von Anfang an aufgesetzt
neue leere Datenbank
neues Contao 3.5.15


Meldung kommt immer noch
kann man einfach so weitermachen und die Meldung ignorieren kommt ja auch bei jeder Modulinstallation....

oder liegt das an Strato oder an der Mysql Version 6.5.3 ???

Manoelo

[Andreas]

Contao Check-Tool!

[Spooky]

Welche MySQL Version hast du tatsächlich? "6.5.3" stimmt nicht.

[manoelo]

5.6.31 bei strato
sorry
contao-check folgt morgen

[manoelo]

contao check
gibt keine fehlermeldung aus
aber das Problem ist immer noch vorhanden und
ich kann auch bei jeder Erweiterung die Tabelle nicht aktuallisieren

Bestehende Spalten ändern
Alle auswählen

ALTER TABLE `tl_files` DROP INDEX `path`, ADD KEY `path` (`path`(333));

[tab]

Hast du Zugriff auf die Datenbank via phpMyAdmin oder ein ähnliches Tool? Wenn du da das fragliche SQL-Statement eingibst, kommt dann eine Fehlermeldung?

[Spooky]

Siehe https://community.contao.org/de/show...icht-m%F6glich

Ist evt. ein Bug im Zusammenhang mit der MySQL Version.

[manoelo]

zugriff via phpmyadmin habe ich --- aber ich bin leider nicht so fit in sql...
was muss ich da tun..?

[tab]

Naja, ich dachte daran den SQL-Befehl dort ins entsprechende SQL-Fenster reinzukopieren, ausführen zu lassen und zu schauen ob ein Fehler kommt und falls ja, welcher. Oder die beiden Befehle separat auszuführen, also zuerst nur den drop index und danach . Also

ALTER TABLE `tl_files` DROP INDEX `path`;
ALTER TABLE `tl_files` ADD KEY `path` (`path`(333));

Aber ist vielleicht auch unnötig. In jedem Fall mal vorher ein Datenbank-Backup machen. Auch wenn es eigentlich unkritisch sein dürfte, weil es nur um einen Index geht und ja hier keine Datensätze in der Tabelle gelöscht oder verändert werden. Steht irgendwas in der Datei system/logs/error.log im Zusammenhang mit dem Datenbankupdate? Ich denke allerdings, es gab schon ein paar ähnliche Fälle in anderen Threads hier im Forum.

[Spooky]

Siehe mein Post davor . Es tritt kein Fehler auf. Entweder hat der query keine Auswirkung oder Contao erkennt die Änderung danach nicht. Im verlinkten Thread ging es ebenfalls um MySQL 5.6. Bisher hatte ich noch nicht die Gelegenheit selbst zu überprüfen, was nun genau vor sich geht.

[manoelo]

ok...
danke

vielleicht kann man den bug ja in der nächsten contao Version beheben

[Spooky]

Ob tatsächlich ein Bug vorliegt oder nicht steht ja noch nicht fest. Dazu müsste man das Problem zuerst reproduzieren und dann analysieren können.

[limonen-zebra]

Ich habe gerade das gleiche "Problem".

Installiert habe ich auch direkt über Contao-Check. War alles grün und startklar
Auch habe ich in den letzten Tagen diese Contao-Version schon mehrfach installiert - ohne "Vorkommnisse".

SQL Version ist 5.6.31
PHP Version ist 5.6
Host ist Strato

[lucina]

Mal interessehalber: welche Datenbankkollation habt Ihr denn eingestellt?

[manoelo]

ich habe jetzt nochmal auf einer anderen Domain das ganze installiert - auch bei strato mit der neuen sql Version 5.6.31...
Problem ist das gleiche und es muss definitiv an der sql version liegen, weil ich noch andere domains bei strato laufen lasse und da läuft contao 3.5.15 perfekt
allerdings mit einer anderen sql versionen

hab auch diese sql Befehle:
ALTER TABLE `tl_files` DROP INDEX `path`;
ALTER TABLE `tl_files` ADD KEY `path` (`path`(333));
durchgeführt
ergebnis: MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze).

Kollation:
utf_8_general_ci

villeicht doch ein kleiner mini käfer?

[limonen-zebra]

Kollation (bei im Installtool)
utf_8_general_ci

Kollation bei Strato
uft8mb4_general_ci

Lässt sich auch nicht umstellen.
Könnte das ein Problem sein?

[tab]

ich habe jetzt nochmal auf einer anderen Domain das ganze installiert - auch bei strato mit der neuen sql Version 5.6.31...
Problem ist das gleiche und es muss definitiv an der sql version liegen, weil ich noch andere domains bei strato laufen lasse und da läuft contao 3.5.15 perfekt
allerdings mit einer anderen sql versionen

hab auch diese sql Befehle:
ALTER TABLE `tl_files` DROP INDEX `path`;
ALTER TABLE `tl_files` ADD KEY `path` (`path`(333));
durchgeführt
ergebnis: MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze).

Kollation:
utf_8_general_ci

villeicht doch ein kleiner mini käfer?

Der zweite Befehl ging auch ohne Fehlermeldung durch? Wenn ja, schau doch mal nach ob der Index 'path' bei der Tabelle tl_files wirklich existiert und was ggf bei Spalte und Größe drinsteht.

[Andreas]

So sieht das mit phpMyAdmin auf Server-Version: 5.5.31-MariaDB - MariaDB Server aus
tl_files_phpMyAdmin_4.4.15.5_-_2016-09-05_17.27.47.png

[Marion]

ALTER TABLE `tl_files` DROP INDEX `path`, ADD KEY `path` (`path`(333));

Ich hatte ein ganz ähnliches Problem mit der tl_search beim Update auf 3.5.16.

Zum Verständnis des SQL-Statements, das heisst übersetzt:
Lösche den Index auf das Feld "path" (Indexe werden zur schnelleren Suche verwendet) und setze "path" als Primärschlüssel.

Das heisst, dass jeder Eintrag in der Tabelle "tl_files" eindeutig über den Wert im Feld "path" identifiziert werden kann. Wenn ein Feld als Primärschlüssel gesetzt wird, wird es automatisch indiziert (deshalb braucht es den separaten Index nicht mehr), und jeder Wert muss eindeutig sein, d.h. er darf nur einmal vorkommen.

Und hier genau lag mein Problem: Ich hatte nämlich doppelte Werte in diesem Feld drin. In der Fehlermeldung stand dann auch etwas wie "duplicate entry". Also löschte ich in der Datenbank die doppelten Einträge. Danach klappte der SQL-Befehl aus dem Contao.

Mein Vorschlag: Schau in der Datenbank, ob das Feld "path" schon als Primärschlüssel gekennzeichnet ist. Das siehst du, wenn du im phpMyAdmin die Tabelle auswählst und auf "Struktur" klickst. Neben dem Feldnamen des Primärschlüssel ist ein gelber Schlüssel zu sehen.
Allerdings muss ich dazu sagen, dass bei meiner 3.5.16-Installation "id" als Primärschlüssel definiert ist und nicht "path" - wurde diese Änderung wieder rückgängig gemacht?

Wenn "path" kein Primärschlüssel ist, dann prüfe das Feld "path" auf doppelte Einträge, lösche jeweils einen davon und führe dann im Contao nochmals den SQL-Befehl durch.

Und hast du den Fehlerlog von Contao schon durchgeschaut? Was steht dort, wenn du den SQL-Befehl ausgeführt hast?

[manoelo]

bei mir hat path einen primärschlüssel
auch bei einer 3.5.16 version wo das Prolem sich leider nicht aufgelöst hat

[Marion]

bei mir hat path einen primärschlüssel
auch bei einer 3.5.16 version wo das Prolem sich leider nicht aufgelöst hat

Na, damit erklärt sich doch schon mal die Reaktion im phpMyAdmin auf den Befehl:

MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze)

Wenns schon gemacht ist, kann die Änderung ja nicht durchgeführt werden.

Machst du mal einen Printscreen von der Struktur der tl_files in phpMyAdmin und postest ihn hier? Vielleicht lässt sich da was ablesen.

[manoelo]

Bildschirmfoto 2016-09-07 um 10.15.18 (2).png

hier das Bildschirmfoto von der tl_files Struktur

[tab]

Jetzt noch in der hier dargestellten Ansicht links auf das Plus bei tl_files klicken und dann auch bei den Indexes, die da unter anderem erscheinen sollten. Dann - falls vorhanden - auf path klicken, damit man sieht, wie der Index aussieht.

[manoelo]

ok


Bildschirmfoto 2016-09-07 um 10.38.57 (2).png

[Marion]

OK, das war jetzt ein bisschen verwirrlich für dich, weil das phpMyAdmin nicht überall gleich ausschaut und ich dir etwas beschrieben habe, das du nicht sehen kannst, nämlich den gelben Schlüssel, der bei mir gerade neben dem Feldnamen steht.

Alles, was unter "Aktion" steht, kann man für das entsprechende Feld ausführen, das zeigt nur indirekt an, wie das Feld definiert ist. Nämlich wenn die Aktion nicht ausführbar ist, heisst das, dass das Feld das schon hat.
Du kannst in der ersten Zeile "id" sehen, dass Primärschlüssel nicht ausführbar ist, das heisst also, auch bei dir ist die id Primärschlüssel und nicht path.
Die Zeile mit path zeigt dir, dass path kein Schlüssel ist und dass es keinen Index hat - das Löschen des Index hat also geklappt.

Dein 2. Befehl ADD KEY `path` (`path`(333)); ist eh merkwürdig wegen der Zahl 333. Deshalb hab ich nochmals ein bisschen gegraben und den folgenden Thread gefunden:

https://community.contao.org/de/show...-Key-Path(333)

Verwendest du die Erweiterung BackupDB? Und hast du mindestens Version 3.2.2 Build 13?

[tab]

Aha, der Index "path" existiert, hat aber nur eine Größe von 255, während normal 333 wären. Da scheint es bei der Datenbank eine Beschränkung zu geben, die niedriger ist als bei anderen Servern.

[manoelo]

Dein 2. Befehl ADD KEY `path` (`path`(333)); ist eh merkwürdig wegen der Zahl 333.
ja aber der taucht ja bei der Installation auf und lässt sich nicht aktuallisieren
es ist keine Erweiterung installiert

Bildschirmfoto 2016-09-07 um 11.21.24 (2).png

[Marion]

Höchstwahrscheinlich handelt es sich um einen unsinnigen Befehl wie beim vorher gelinkten Thread. Die Installation scheint ja fehlerfrei zu laufen, abgesehen von dieser Änderung, die Contao auszuführen versucht und nicht kann. Weiss jemand, wo anstehende DB-Änderungen im Contao gespeichert werden?

Hast du mal versucht, die Datei update.phar.php im Verzeichnis contao zu löschen? Geht der Eintrag dann weg?

[Andreas]

Das wird nirgendwo gespeichert. Contao rödelt die DCA durch und ermittelt daraus die notwendige DB-Struktur. Die Beschreibungen liegen in den dca/ Ordnern.

$GLOBALS['TL_DCA'][$tabellenname]['config']['sql'];
// und
$GLOBALS['TL_DCA'][$tabellenname]['fields'][$feldname]['sql']; 

Wenn die DB da beim Index ne Beschränkung auf 255 hat, kann man mal versuchen den Wert von 333 auf 255 zu ändern.

// system/dcaconfig.php
$GLOBALS['TL_DCA']['tl_files']['config']['sql']['keys']['path'] = 'index(255)'; 

Ich weiß aber nicht, was ein kleinerer Wert dort für Auswirkungen haben wird.

[manoelo]

Ja das wars vielleicht (hope

jedenfalls kommt die Meldung jetzt nicht mehr, nachdem ich den code von andreas eingefügt habe

// system/dcaconfig.php
$GLOBALS['TL_DCA']['tl_files']['config']['sql']['keys']['path'] = 'index(255)';

thanks a lot
ich forsche nochmal bei strato warum es da offensichtlich eine Beschränkung gibt

schöne Grüße
Manoelo

[do_while]

Ist Strato nicht der Service-Champion?
Wenn man das Problem jetzt so gut beschreiben kann, sollte der Support doch qualifiziert helfen können.

[buntwelt]

Ich habe gerade genau dieses Problem, Setting:

Contao 3.5.16

MySQL 5.6.31 mit PHP 5.6 bei Strato

Jungfraeuliche Contao-Installation mit den neuesten Contao-Check (contao-check-8f8a2eb), aber sofort nach dem Eintrag der Daten im Installationstool kommt:

ALTER TABLE `tl_files` DROP INDEX `path`, ADD KEY `path` (`path`(333));

Ich habe versucht, die SQL-Aenderung direkt in PHPMyAdmin auszufuehren, Ergebnis:

MySQL lieferte ein leeres Resultat zurück (d.h. null Datensätze). (Die Abfrage dauerte 0.0054 Sekunden.)

Der Eintrag

// system/dcaconfig.php
$GLOBALS['TL_DCA']['tl_files']['config']['sql']['keys']['path'] = 'index(255)';

macht zwar die Fehlermeldung weg, aber ich bekomme beim Aufruf der Seite laufend Meldungen ueber Duplicate entrys:

---

Fatal error: Uncaught exception Exception with message Query error: Duplicate entry 'f6edab87e072f4b6996524bbcfdd4400-3' for key 'checksum_pid' (INSERT INTO tl_search (tstamp, url, title, protected, filesize, groups, pid, language, text, checksum) VALUES (1473727032, 'http://vorschau.kk-spezialgeruestbau.de/', 'Home', '', '11.70', 0, '3', 'de', 'Home K&K Spezialgerüstbau GmbH - Ihr professioneller Dienstleiter Seit nunmehr über 25 Jahren sind wir für Industrie, Bau und Handwerk ein zuverlässiger Partner im Bereich Gerüstbau. Unsere eigenen Ingenieurskompetenzen ergänzen wir in Zusammenarbeit mit erfahrenen Ingenieurbüros. Jedes neue Bauvorhaben wird von uns unabhängig von der Auftragsgröße gewissenhaft vorbereitet und ausgeführt. Darüber hinaus legen wir Wert auf umfassende und faire Kundenberatung. Wir freuen uns über einen großen Kundenstamm und sehen diesen als Bestätigung für unsere Arbeitsweise an. Wir bearbeiten Ihre Anfrage umgehend und stehen Ihnen für Fragen gerne telefonisch oder per eMail zur Verfügung. Benutzen Sie einfach unser Kontaktformular oder klicken Sie auf eine der untenstehenden Telefonnummern. Leistungen »Arbeitsgerüste« »Schutzgerüste« »Industriegerüste« »Traggerüste« »Fassadengerüste« »Raumgerüste« »Fahrgerüste« »Wetterschutzdächer« »Hängegerüste« »Sonderkonstruktionen« K&K Spezialgerüstbau GmbH Schmidmühlenerstr. 11 93133 Burglengenfeld C. Kühlinger: 0170 9332328 D. Kohler: 0176 24950203 eMail: info@kk-spezialgeruestbau.de K&K Spezialgerüstbau GmbH,', 'f6edab87e072f4b6996524bbcfdd4400')) thrown in system/modules/core/library/Contao/Database/Statement.php on line 295

#0 system/modules/core/library/Contao/Database/Statement.php(264): Contao\Database\Statement->query()
#1 system/modules/core/library/Contao/Search.php(214): Contao\Database\Statement->execute()
#2 system/modules/core/classes/FrontendTemplate.php(330): Contao\Search::indexPage(Array)
#3 system/modules/core/classes/FrontendTemplate.php(124): Contao\FrontendTemplate->addToSearchIndex()
#4 system/modules/core/pages/PageRegular.php(190): Contao\FrontendTemplate->output(true)
#5 system/modules/core/controllers/FrontendIndex.php(285): Contao\PageRegular->generate(Object(Contao\PageModel), true)
#6 index.php(20): Contao\FrontendIndex->run()
#7 {main}

---

Ich habee auch schon die Kollation der MySQL-Datenbank an die Version des Installationstools angeglichen (utf8_general_ci) - ohne Erfolg.

Das Setting bei Strato ist:

Datenbank-Server

Server: rdbms via TCP/IP
Server-Typ: MySQL
Server Version: 5.6.31-log - Source distribution
Protokoll-Version: 10
Server Zeichensatz: UTF-8 Unicode (utf8)

Webserver

Apache/2.2.31 (Unix)
Datenbank-Client Version: libmysql - 5.5.46
PHP-Erweiterung: mysqli Dokumentation

phpMyAdmin

Versionsinformationen: 4.2.12


Der Kunde hat mehrere Seiten bei Strato am Laufen, ein Providerwechsel ist ausgeschlossen

Zu sehen ist es hier: http://vorschau.kk-spezialgeruestbau.de/

Ich bin mit meinem Latein am Ende und fuer jeden Hinweis dankbar.

[Spooky]

aber ich bekomme beim Aufruf der Seite laufend Meldungen ueber Duplicate entrys:

Siehe https://community.contao.org/de/show...ATE-auf-3-5-16 » https://github.com/contao/core/issues/8460 » https://github.com/contao/core/commi...30a625162091e9