Stand: November 2020
Zur Info und Beruhigung:
Das Problem ist nur bei DB-Version 5.7 aufgetreten
Bei allen anderen DB-Versionen gab und gibt es diese Schwierigkeiten meines Wissens nicht.
Es gibt sogar Installation mit 5.7, die keine Probleme machen. Hier hat wahrscheinlich der Provider etwas getan.
Zum Problem:
Beispiel – Tabelle clm_saison
In einer Aktion in 2016 haben wir wegen 5.7 die init-Werte der Felder vom Typ datetime von „0000-00-00 00:00:00“ auf „1970-01-01 00:00:00“ verändert und es schien, die Schwierigkeiten mit 5.7 wären gelöst.
Doch nun wurde festgestellt, eine Tabelle, die
- Datensätze mit „0000-00-00 00:00:00“-Werten in datetime-Feldern oder/und
- Datensätze mit „0000-00-00“-Werten in date-Feldern
enthält, kann man nicht ändern wie gewohnt!!
So führt z.B.
ALTER TABLE `#__clm_saison` ADD `rating_type` tinyint(1) unsigned NOT NULL DEFAULT '0' AFTER `datum`
zu MySql-Fehler
#1292 - Falscher datetime-Wert: '0000-00-00 00:00:00' für Feld
'checked_out_time' in Zeile 1
Werden die
„0000-00-00 00:00:00“-Werten durch „1970-01-01 00:00:00“ bzw. die
„0000-00-00“-Werten durch „1970-01-01“ jedoch im Vorfeld ersetzt, gibt es keine Schwierigkeiten beim DB-Update.
Lösung oder zumindest Zwischenlösung:
- - die einfache Routine dbcorrection, die alle datetime-Felder mit Inhalt „0000-00-00 00:00:00“ auf „1970-01-01 00:00:00“ sowie alle date-Felder mit Inhalt „0000-00-00“ auf „1970-01-01“ setzt, ist seit CLM-Version 3.8.6 Teil des Projektes
- der Aufruf kann bei Bedarf über http://.../administrator/index.php?option=com_clm&view=forceDBCorrection erfolgen. Admin-Rechte sind dazu erforderlich.
-