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.

-