Invalid datetime format: 1292 Incorrect datetime value: '1666646235' for column

[woelfin]

Ich habe ein Update von 3.5.40 auf 4.9 durchgeführt. War schwierig und zeitraubend und mit vielen Problemen behaftet, die ich aber soweit alle gelöst habe. Pro Forma habe ich noch einen Test des Kontaktformulars durchgeführt, und da wird mir nicht die Dankesseite angezeigt sondern Fehler! Das Formular ist angekommen, aber der Fehler muss weg.

In der Log-Datei steht: Invalid datetime format: 1292 Incorrect datetime value: '1666646235' for column...

Beim googlen fand ich Hinweise, dass es mit der Umstellung der DB auf den Strict-Mode (der beim Update gefordert wurde und den ich durchgeführt habe) zusammenhängen soll.
Muss ich an der Struktur der DB - speziell dem Datumsfeld im Formular was ändern?
Die Spalte hat folgendes Format:
tstamp int(10) UNSIGNED Nein 0

Hat jemand eine Idee? Danke im Voraus!

[Spooky]

Poste immer die gesamte Fehlermeldung, am besten als Stack Trace aus dem Debug-Mode.

[woelfin]

Leider weiß ich nicht, was ein Stack Trace ist. Ich habe die Log-Datei hochgeladen. Ich hoffe, dass es hilft.

[woelfin]

Doctrine\DBAL\Exception\DriverException:
An exception occurred while executing 'INSERT INTO kontakte (`tstamp`, `vorname`, `name`, `email`, `telefon`, `subject`, `message`, `referrer`) VALUES (1666901903, 'Testitia', 'Testerin', 'test@test.de', '0123456789', 'allgemein', 'Test', 'a:1:{i:0;s:7:\"anderes\";}')':

SQLSTATE[22007]: Invalid datetime format: 1292 Incorrect datetime value: '1666901903' for column `db49-bienenmensch`.`kontakte`.`tstamp` at row 1

  at vendor/doctrine/dbal/lib/Doctrine/DBAL/Driver/AbstractMySQLDriver.php:128
  at Doctrine\DBAL\Driver\AbstractMySQLDriver->convertException()
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:182)
  at Doctrine\DBAL\DBALException::wrapException()
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/DBALException.php:159)
  at Doctrine\DBAL\DBALException::driverExceptionDuringQuery()
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:2226)
  at Doctrine\DBAL\Connection->handleExceptionDuringQuery()
     (vendor/doctrine/dbal/lib/Doctrine/DBAL/Connection.php:1313)
  at Doctrine\DBAL\Connection->executeQuery()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Database/Statement.php:274)
  at Contao\Database\Statement->query()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Database/Statement.php:248)
  at Contao\Database\Statement->execute()
     (vendor/contao/core-bundle/src/Resources/contao/forms/Form.php:541)
  at Contao\Form->processFormData()
     (vendor/contao/core-bundle/src/Resources/contao/forms/Form.php:259)
  at Contao\Form->compile()
     (vendor/contao/core-bundle/src/Resources/contao/classes/Hybrid.php:232)
  at Contao\Hybrid->generate()
     (vendor/contao/core-bundle/src/Resources/contao/forms/Form.php:94)
  at Contao\Form->generate()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Controller.php:624)
  at Contao\Controller::getContentElement()
     (vendor/contao/core-bundle/src/Resources/contao/modules/ModuleArticle.php:218)
  at Contao\ModuleArticle->compile()
     (vendor/contao/core-bundle/src/Resources/contao/modules/Module.php:214)
  at Contao\Module->generate()
     (vendor/contao/core-bundle/src/Resources/contao/modules/ModuleArticle.php:71)
  at Contao\ModuleArticle->generate()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Controller.php:552)
  at Contao\Controller::getArticle()
     (vendor/contao/core-bundle/src/Resources/contao/library/Contao/Controller.php:393)
  at Contao\Controller::getFrontendModule()
     (vendor/contao/core-bundle/src/Resources/contao/pages/PageRegular.php:173)
  at Contao\PageRegular->prepare()
     (vendor/contao/core-bundle/src/Resources/contao/pages/PageRegular.php:53)
  at Contao\PageRegular->getResponse()
     (vendor/contao/core-bundle/src/Resources/contao/controllers/FrontendIndex.php:343)
  at Contao\FrontendIndex->renderPage()
     (vendor/symfony/http-kernel/HttpKernel.php:159)
  at Symfony\Component\HttpKernel\HttpKernel->handleRaw()
     (vendor/symfony/http-kernel/HttpKernel.php:81)
  at Symfony\Component\HttpKernel\HttpKernel->handle()
     (vendor/symfony/http-kernel/Kernel.php:201)
  at Symfony\Component\HttpKernel\Kernel->handle()
     (web/index.php:31)

[Spooky]

Du hast das Feld "tstamp" in deiner "kontakte" Tabelle als "datetime" konfiguriert, übergibst aber einen Unix Timestamp statt einen datetime String.

[woelfin]

Vielen Dank, Spoky, für Deinen Hinweis. Leider habe ich nichts gemacht, sondern nur ein Update von V3.5 auf V 4.9 vollzogen. Auch das versionsmäßig passende Theme habe ich hochgeladen. Ich nehme an, dass das Formularmodul das Originale von Contao ist. Also müsste der Fehler bei V 4.9 von Contao liegen oder die Migration der DB hat beim Update nicht funktioniert. Ich werde jetzt versuchen, durch Detektivarbeit herauszubekommen, ob das Script oder die DB "schuld" ist. Da ich noch ein Projekt mit dem selben Theme habe, was schon unter 4.9 läuft, werde ich mal die Struktur der Kontaktformulartabelle vergleichen.

Ergebnis:

In der Vergleichsprojekt gibts kein separate Tabelle "Kontakte", Vergleich also nicht möglich.
Die Spalte der Tabelle Kontakte ist in der Tabelle V 3.5 und in der V 4.9 so konfiguriert (bei V 3.5 funktioniert die Danke-Seite):

Spalte Typ Null Standard
tstamp timestamp Ja current_timestamp()

Ich finde da kein datetime :-(

[Spooky]

Der Fehler liegt nicht bei Contao. Die Tabelle "kontakte" hast du selbst angelegt. "timestamp" ist der falsche Feldtyp, denn MySQL erwartet sich hier eben einen String der so aussieht: YYYY-MM-DD HH:MM:SS (siehe https://dev.mysql.com/doc/refman/8.0/en/datetime.html). Du lässt dort aber Unix Timestamps speichern.

Den Fehler kannst du beheben, indem du in deinem processFormData bzw. storeFormData Hook eben das korrekte Format speichern lässt - oder indem du das Feld "tstamp" in deiner "kontakte" Tabelle auf integer änderst.

[woelfin]

Vielen Dank!!!! Du bist mein Retter :-)

Die Tabelle ist 2017 angelegt worden und am Projekt hat noch jemand anderes mitgewirkt. Aber egal, ich stecke auch nur wenig in der Materie und unter V 3.5 hat es ja auch funktioniert, zumindest kam dort kein Fehler, aber in der Tabelle bestand das Datum nur aus Nullen ;-(. Deshalb habe ich auch die Struktur in der Tabelle geändert. Außerdem hätte ich bei der anderen Version nicht gewusst, was ich da machen soll und ob das dann updatesicher ist.
Einen wunderschönen sonnigen Tag wünsche ich Dir

[Spooky]

und unter V 3.5 hat es ja auch funktioniert, zumindest kam dort kein Fehler, aber in der Tabelle bestand das Datum nur aus Nullen ;-(

Das liegt aber nicht an Contao, sondern an der Datenbank bzw. Datenbankverbindung. Wenn dein Datenbankserver bspw. von Haus aus im Strict Mode läuft, oder du unter Contao 4.9 die Datenbankverbindung entsprechend konfiguriert hast, dann erlaubt die Datenbank es eben nicht mehr falsche Daten zu speichern. Also vorausgesetzt das Feld kontakte.tstamp war auch schon unter Contao 3 datetime bzw. timestamp, statt integer.

[Spooky]

Deshalb habe ich auch die Struktur in der Tabelle geändert.

Was genau hast du geändert? Wenn du kontakte.tstamp selbst von integer auf timestamp geändert hast, dann ist das die Ursache

[woelfin]

kontakte.tstamp sah vorher so aus und brachte den Fehler, weil Contao V 4.9 von der DB den Strict-Mode verlangte, den ich auch eingestellt habe:

Spalte Typ Null Standard
tstamp timestamp Ja current_timestamp()


und sieht nach meiner Änderung jetzt so aus, wie in allen anderen Tabellen (z.B. tl_form und tl_form_:

tstamp int (10)