Falscher Datums-/Uhrzeitwert Datenbank-Fehlernummer: 1292

Nach dem Upgrade auf MySQL 5.7 stellte ich fest, dass dieser Fehler in zufälligen Situationen auftrat, selbst wenn ich kein Datum in der Abfrage angegeben habe.

Dies scheint darauf zurückzuführen zu sein, dass vorherige Versionen von MySQL Datumsangaben wie 0000-00-00 00:00:00 (standardmäßig) unterstützten. In 5.7.4 wurden jedoch einige Änderungen an der Einstellung NO_ZERO_DATE vorgenommen. Wenn bei der Verwendung einer neueren MySQL-Version noch alte Daten vorhanden sind, können zufällige Fehler auftreten.

Ich musste eine solche Abfrage durchführen, um alle Nulldaten auf ein anderes Datum zurückzusetzen.

# If the columns supports NULL, use that
UPDATE table SET date_column = NULL WHERE date_column < '1000-01-01';

# Otherwise supply another default date
UPDATE table SET date_column = '1970-01-01' WHERE date_column < '1000-01-01';

Alternativ können Sie möglicherweise die Einstellung NO_ZERO_DATE anpassen, beachten Sie jedoch, was die Dokumente dazu sagen:

Der NO_ZERO_DATE-Modus beeinflusst, ob der Server "0000-00-00" als gültiges Datum zulässt. Ihre Auswirkung hängt auch davon ab, ob der strikte SQL-Modus aktiviert ist.

• Wenn dieser Modus nicht aktiviert ist, ist "0000-00-00" zulässig, und Einfügungen geben keine Warnung aus.

• Wenn dieser Modus aktiviert ist, ist '0000-00-00' zulässig, und Einfügungen geben eine Warnung aus.

• Wenn dieser Modus und der strikte Modus aktiviert sind, ist '0000-00-00' nicht zulässig und Einfügungen führen zu einem Fehler, es sei denn, IGNORE wird ebenfalls angegeben. Für INSERT IGNORE und UPDATE IGNORE ist '0000-00-00' zulässig, und Einfügungen erzeugen eine Warnung.

Seit MySQL 5.7.4 ist NO_ZERO_DATE veraltet. In MySQL 5.7.4 bis 5.7.7 macht NO_ZERO_DATE nichts, wenn es explizit benannt wird. Stattdessen ist der Effekt im strengen SQL-Modus enthalten. In MySQL 5.7.8 und höher hat NO_ZERO_DATE eine Wirkung, wenn es explizit benannt wird und nicht wie im Fall von MySQL 5.7.4 im strikten Modus enthalten ist. Es sollte jedoch in Verbindung mit dem strikten Modus verwendet werden und ist standardmäßig aktiviert. Eine Warnung wird angezeigt, wenn NO_ZERO_DATE aktiviert ist, ohne den strikten Modus zu aktivieren, oder umgekehrt. Weitere Informationen finden Sie unter Änderungen des SQL-Modus in MySQL 5.7.

Da NO_ZERO_DATE veraltet ist, wird er in einer zukünftigen MySQL-Version als separater Modusname entfernt und dessen Auswirkungen im strengen SQL-Modus berücksichtigt.

From http://dev.mysql.com/doc/refman/5.7/de/sql-mode.html#sqlmode_no_zero_date

Kurze Antwort - NOW() in Ihrer Abfrage sollte mit einer MySQL-Variable DATETIME perfekt funktionieren.

Längere Antwort - Ich bin nicht sicher, wie Sie jemals gesehen haben, dass +0000 funktioniert. Die DATETIME-Spalte wird als 'YYYY-MM-DD HH:MM:SS' formatiert. Wenn es um Zeitzonenunterschiede geht, müssen Sie diese normalerweise programmgesteuert behandeln. MySQL konvertiert lokale Zeiten in UTC und zurück, wenn TIMESTAMP-Daten gespeichert und abgerufen werden. Dies geschieht jedoch nicht mit DATETIME oder anderen Date/Time-Spalten.

Falscher Datums-/Uhrzeitwert Datenbank-Fehlernummer: 1292

Der Datentyp TIMESTAMP wird für Werte verwendet, die sowohl Datums- als auch Zeitteile enthalten. TIMESTAMP hat einen Bereich von '1970-01-01 00:00:01' UTC bis '2038-01-19 03:14:07' UTC.

Der DATETIME-Typ wird für Werte verwendet, die sowohl Datums- als auch Zeitteile enthalten. MySQL ruft DATETIME-Werte im 'YYYY-MM-DD HH:MM:SS'-Format ab und zeigt sie an. Der unterstützte Bereich ist '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.

Sie sollten diesen Typ verwenden in: DateTime-Format

INSERT INTO `activitylog` 
(`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) 
VALUES 
('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43')

https://dev.mysql.com/doc/refman/5.0/de/date-and-time-types.html

https://dev.mysql.com/doc/refman/5.0/de/datetime.html

http://bugs.mysql.com/bug.php?id=70188

update: 1

sie sollten die Variable space wie Ihren Code '2014-04-02 08:49:43 +0000' entfernen und den Code wie '2014-04-02 08:49:43+0000' ändern, da die vollständige Abfrage folgendermaßen lautet:

INSERT INTO `activitylog` 
(`tablename`, `row`, `user_id`, `description`, `action`, `private`,`created`) 
VALUES ('user', '1', '1', 'People', 'Updated', 0, '2014-04-02 08:49:43+0000')

siehe hier: http://sqlfiddle.com/#!2/a2581/23099

Ok, also hatte ich den gleichen Fehler. Um dies zu beheben, wurden folgende Codezeilen verwendet, um die Datenbank abzufragen, mit der ich Probleme hatte:

SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session;
SET sql_mode = '';
SET GLOBAL sql_mode = '';

In der ersten Codezeile (SELECT) wird die aktuelle Einstellung für 'SESSION' und 'GLOBAL' angezeigt. Wenn Sie beide auf leere Zeichenfolgen setzen und die Auswahl erneut ausführen, sollten sie nichts zurückgeben (leer sein).

Möglicherweise müssen Sie auch SET SESSION sql_mode = ''; verwenden, aber dadurch wurde das Problem für mich gelöst. Im Grunde war eine der Einstellungen dort, wie das Datum in die Datenbank kam. Das Löschen von NO_ZERO_IN_DATE und der anderen Datumsoption hat mir nicht geholfen.

Meine Website funktioniert jetzt so, wie sie soll. Hoffentlich hilft das.

Das ursprüngliche my.cnf hatte sql_model wie folgt festgelegt:

sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Ich habe versucht, NO_ZERO_IN_DATE und NO_ZERO_DATE zu entfernen, aber es hatte keine Auswirkungen. Wenn ich jedoch alle Begriffe entfernt habe (sql_mode empty), ist der Fehler verschwunden.

Ich ging zurück zum ursprünglichen sql_mode und dachte, ich würde die Begriffe 1-by-1 entfernen, um zu sehen, welche Ursache die Ursache war. Der erste Versuch bestand darin, STRICT_TRANS_TABLES zu entfernen:

sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Kein Fehler. Es scheint also, dass STRICT_TRANS_TABLES die Ursache war.