MySQL Valeur datetime incorrecte: «0000-00-00 00:00:00»

J'ai récemment repris un ancien projet qui a été créé il y a 10 ans. Il utilise MySQL 5.1.

Entre autres choses, je dois changer le jeu de caractères par défaut de latin1 à utf8.

À titre d'exemple, j'ai des tableaux comme celui-ci:

  CREATE TABLE `users` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `first_name` varchar(45) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `last_name` varchar(45) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `username` varchar(127) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `email` varchar(127) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `pass` varchar(20) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `active` char(1) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT 'Y',
    `created` datetime NOT NULL,
    `last_login` datetime DEFAULT NULL,
    `author` varchar(1) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT 'N',
    `locked_at` datetime DEFAULT NULL,
    `created_at` datetime DEFAULT NULL,
    `updated_at` datetime DEFAULT NULL,
    `ripple_token` varchar(36) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `ripple_token_expires` datetime DEFAULT '2014-10-31 08:03:55',
    `authentication_token` varchar(255) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `index_users_on_reset_password_token` (`reset_password_token`),
    UNIQUE KEY `index_users_on_confirmation_token` (`confirmation_token`),
    UNIQUE KEY `index_users_on_unlock_token` (`unlock_token`),
    KEY `users_active` (`active`),
    KEY `users_username` (`username`),
    KEY `index_users_on_email` (`email`)
  ) ENGINE=InnoDB AUTO_INCREMENT=1677 DEFAULT CHARSET=utf8 CHECKSUM=1 DELAY_KEY_WRITE=1 ROW_FORMAT=DYNAMIC

J'ai configuré mon propre Mac pour y travailler. Sans trop y penser, j'ai lancé "brew install mysql" qui a installé MySQL 5.7. J'ai donc des conflits de version.

J'ai téléchargé une copie de cette base de données et je l'ai importée.

Si j'essaye d'exécuter une requête comme celle-ci:

  ALTER TABLE users MODIFY first_name varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci    NOT NULL  

J'obtiens cette erreur:

  ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'created' at row 1

J'ai pensé que je pourrais résoudre ce problème avec:

  ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-01 00:00:00';
  Query OK, 0 rows affected (0.06 sec)
  Records: 0  Duplicates: 0  Warnings: 0

mais j'obtiens:

  ALTER TABLE users MODIFY first_name varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci    NOT NULL ;
  ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'created' at row 1

Dois-je mettre à jour chaque valeur?

Ma suggestion si c'est le cas où la table est vide ou pas très grande est d'exporter les instructions create sous forme de fichier .sql, réécrivez-les comme vous le souhaitez. Faites de même si vous avez des données existantes, c'est-à-dire exportez des instructions d'insertion (je recommande de le faire dans un fichier séparé en tant que instructions de création). Enfin, supprimez la table et exécutez d'abord l'instruction create, puis insérez.

Vous pouvez utiliser pour cela l'une ou l'autre des mysqldumpcommandes incluses dans votre installation MySQL ou vous pouvez également installer MySQL Workbench, qui est un outil graphique gratuit qui inclut également cette option de manière très personnalisable sans avoir à rechercher des options de commande spécifiques.

Je n'ai pas pu faire ça:

UPDATE users SET created = NULL WHERE created = '0000-00-00 00:00:00'

(sur MySQL 5.7.13).

J'ai continué à recevoir l' Incorrect datetime value: '0000-00-00 00:00:00'erreur.

Étrangement, cela a fonctionné: SELECT * FROM users WHERE created = '0000-00-00 00:00:00'. Je ne sais pas pourquoi le premier échoue et le second fonctionne ... peut-être un bogue MySQL?

Dans tous les cas, cette requête UPDATE a fonctionné:

UPDATE users SET created = NULL WHERE CAST(created AS CHAR(20)) = '0000-00-00 00:00:00'

Modification de la valeur par défaut d'une colonne avec une ALTER TABLEinstruction, par ex.

 ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-02'

... ne modifie aucune valeur déjà stockée. La valeur "par défaut" s'applique aux lignes insérées et pour lesquelles aucune valeur n'est fournie pour la colonne.

Quant à savoir pourquoi vous rencontrez l'erreur, il est probable que le sql_modeparamètre de votre session inclut NO_ZERO_DATE.

Référence: http://dev.mysql.com/doc/refman/5.7/en/sql-mode.html#sqlmode_no_zero_date

Lorsque vous avez effectué l '"importation", les instructions SQL qui ont effectué l'INSERT dans cette table ont été exécutées dans une session qui n'autorisait aucune date.

Pour voir le paramètre sql_mode:

SHOW VARIABLES LIKE 'sql_mode' ;

-ou-

SELECT @@sql_mode ;

En ce qui concerne la façon de «résoudre» le problème actuel, afin que l'erreur ne soit pas générée lorsque vous exécutez l' ALTER TABLEinstruction.

Plusieurs options:

1) modifiez le sql_modepour autoriser zéro date, en supprimant NO_ZERO_DATEet NO_ZERO_IN_DATE. La modification peut être appliquée dans le fichier my.cnf, donc après un redémarrage de MySQL Server, la sql_modevariable sera initialisée avec le paramètre dans my.cnf.

Pour un changement temporaire, nous pouvons modifier le paramètre en une seule session, sans nécessiter de changement global.

-- save current setting of sql_mode
SET @old_sql_mode := @@sql_mode ;

-- derive a new value by removing NO_ZERO_DATE and NO_ZERO_IN_DATE
SET @new_sql_mode := @old_sql_mode ;
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_DATE,'  ,','));
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_IN_DATE,',','));
SET @@sql_mode := @new_sql_mode ;

-- perform the operation that errors due to "zero dates"

-- when we are done with required operations, we can revert back
-- to the original sql_mode setting, from the value we saved
SET @@sql_mode := @old_sql_mode ;

2) modifiez la createdcolonne pour autoriser les valeurs NULL et mettez à jour les lignes existantes pour changer les dates zéro en valeurs nulles

3) mettre à jour les lignes existantes pour changer les dates zéro en une date valide

Nous n'avons pas besoin d'exécuter des instructions individuelles pour mettre à jour chaque ligne. Nous pouvons mettre à jour toutes les lignes d'un seul coup (en supposant qu'il s'agisse d'une table de taille raisonnable. Pour une table plus grande, pour éviter une énorme génération de restauration / annulation, nous pouvons effectuer l'opération par tranches de taille raisonnable.)

Dans la question, la AUTO_INCREMENTvaleur indiquée pour la définition de la table nous assure que le nombre de lignes n'est pas excessif.

Si nous avons déjà modifié la createdcolonne pour autoriser les NULLvaleurs, nous pouvons faire quelque chose comme ceci:

UPDATE  `users` SET `created` = NULL WHERE `created` = '0000-00-00 00:00:00'

Ou, nous pouvons les définir sur une date valide, par exemple le 2 janvier 1970

UPDATE  `users` SET `created` = '1970-01-02' WHERE `created` = '0000-00-00 00:00:00'

(Notez qu'une valeur datetime du 1er janvier 1970 à minuit ( '1970-01-01 00:00:00') est une "date zéro". Elle sera évaluée comme étant'0000-00-00 00:00:00'

Je l'ai réparé en faisant cela avant la requête

SET SQL_MODE='ALLOW_INVALID_DATES';

Selon le manuel de référence de MySQL 5.7 :

Le mode SQL par défaut de MySQL 5.7 inclut les modes suivants: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER et NO_ENGINE_SUBSTITUTION.

Puisque ce 0000-00-00 00:00:00n'est pas une DATETIMEvaleur valide , votre base de données est cassée. C'est pourquoi MySQL 5.7 - qui est livré avec le NO_ZERO_DATEmode activé par défaut - génère une erreur lorsque vous essayez d'effectuer une opération d'écriture.

Vous pouvez corriger votre table en mettant à jour toutes les valeurs non valides en une autre valide, comme NULL:

UPDATE users SET created = NULL WHERE created < '0000-01-01 00:00:00'

Aussi, pour éviter ce problème, je vous recommande de toujours définir l'heure actuelle comme valeur par défaut pour vos createdchamps similaires, afin qu'ils soient automatiquement remplis INSERT. Faites simplement:

ALTER TABLE users
ALTER created SET DEFAULT CURRENT_TIMESTAMP

SET sql_mode = 'NO_ZERO_DATE';
UPDATE `news` SET `d_stop`='2038-01-01 00:00:00' WHERE `d_stop`='0000-00-00 00:00:00'

Voici ce que ma solution PhpMyAdmin / Fedora 29 / MySQL 8.0 (par exemple):

set sql_mode='SOMETHING'; ne fonctionne pas , l'appel de commande a réussi mais rien n'a changé.

set GLOBAL sql_mode='SOMETHING'; changer la configuration globale changement permanent.

set SESSION sql_mode='SOMETHING'; modifier la configuration de session La variable SESSION affecte uniquement le client actuel.

https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

Alors je fais ceci:

• Obtenez SQL_MODE: SHOW VARIABLES LIKE 'sql_mode';
• Résultat : ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
• Supprimer sur le résultat: NO_ZERO_IN_DATE,NO_ZERO_DATE
• Définir une nouvelle configuration: set GLOBAL SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'

Vous pouvez supprimer ou ajouter un autre mode de la même manière.

Ceci est utile pour changer global pour l'utilisation et le test des frameworks ou sql_mode doit être spécifié dans chaque fichier ou groupe de requêtes.

Adapté d'une question posée ici: comment-puis-je-désactiver-mysql-strict-mode

Exemple: installez le dernier contenu Joomla 4.0-alpha.

Edit: Dans PhpMyadmin, si vous avez le contrôle du serveur, vous pouvez modifier le sql_mode(et tous les autres paramètres) directement dansPlus > Variables > sql_mode

Vous pouvez modifier le type de créé champ à partir datetimede varchar(255), vous pouvez définir (mise à jour) tous les enregistrements qui ont la valeur "0000-00-00 00:00:00"à NULL.

Maintenant, vous pouvez faire vos requêtes sans erreur. Une fois que vous avez terminé, vous pouvez modifier le type de champ créé en datetime.

J'ai également cette erreur après la mise à niveau de MySQL de 5.6 à 5.7

J'ai compris que la meilleure solution pour moi était de combiner certaines des solutions ici et d'en faire quelque chose qui fonctionnait avec le minimum d'entrée.

J'utilise MyPHPAdmin pour la simplicité de l'envoi des requêtes via l'interface car je peux alors vérifier la structure et tout cela facilement. Vous pouvez utiliser ssh directement ou une autre interface. La méthode doit être similaire ou identique de toute façon.

...

1.

Vérifiez d'abord l'erreur réelle lorsque vous essayez de réparer la base de données:

joomla.jos_menu Remarque: Les colonnes TIME / TIMESTAMP / DATETIME de l'ancien format ont été mises à niveau vers le nouveau format.

Avertissement: valeur datetime incorrecte: '0000-00-00 00:00:00' pour la colonne 'checked_out_time' à la ligne 1

Erreur: valeur par défaut non valide pour "checked_out_time"

status: l'opération a échoué

Cela me dit que la colonne check_out_time dans la table jos_menu doit avoir toutes les mauvaises dates corrigées ainsi que la "valeur par défaut" changée.

...

2.

J'exécute la requête SQL en fonction des informations du message d'erreur:

UPDATE jos_menu SET checked_out_time = '1970-01-01 08:00:00' WHERE checked_out_time = 0

Si vous obtenez une erreur, vous pouvez utiliser la requête ci-dessous à la place qui semble toujours fonctionner:

UPDATE jos_menu SET checked_out_time = '1970-01-01 08:00:00' WHERE CAST(checked_out_time AS CHAR(20)) = '0000-00-00 00:00:00'

...

3.

Ensuite, une fois que cela est fait, j'exécute la deuxième requête SQL:

ALTER TABLE `jos_menu` CHANGE `checked_out_time` `checked_out_time` DATETIME NULL DEFAULT CURRENT_TIMESTAMP;

Ou dans le cas où c'est une date qui doit être NULL

ALTER TABLE `jos_menu` CHANGE `checked_out_time` `checked_out_time` DATETIME NULL DEFAULT NULL;

...

Si j'exécute la base de données de réparation maintenant, j'obtiens:

joomla.jos_menu OK

...

Fonctionne très bien :)

Vérifier

SELECT @@sql_mode;

si vous voyez des éléments "ZERO_DATE" là-dedans, essayez

SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_ZERO_DATE',''));   
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_ZERO_IN_DATE',''));   

Déconnectez-vous et reconnectez-vous à votre client (c'est étrange) et réessayez

Rendre le mode SQL non strict

si vous utilisez laravel, allez dans config-> database, allez dans les paramètres mysql et définissez le mode strict sur false

J'ai eu un problème similaire mais dans mon cas, une ligne avait la valeur NULL.

donc d'abord je mets à jour le tableau:

update `my_table`set modified = '1000-01-01 00:00:00' WHERE modified is null

problème résolu, du moins dans mon cas.

J'ai aussi

SQLSTATE [22007]: Format de date / heure non valide: 1292 Valeur de date / heure incorrecte: '0000-00-00 00:00:00' pour la colonne

info d'erreur

Résoudre ce problème en changeant 0000-00-00 00:00:00 de 1970-01-01 08:00:00

1970-01-01 08:00:00 L'horodatage unix est 0

J'ai trouvé la solution sur https://support.plesk.com/hc/en-us/articles/115000666509-How-to-change-the-SQL-mode-in-MySQL . J'avais ceci:

mysql> show variables like 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                                     |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

Remarquez les NO_ZERO_IN_DATE,NO_ZERO_DATErésultats ci-dessus. J'ai supprimé cela en faisant ceci:

mysql> SET sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected, 1 warning (0.00 sec)

Ensuite, j'ai eu ceci:

mysql> show variables like 'sql_mode';
+---------------+--------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                        |
+---------------+--------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+--------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

Après cela, je pourrais utiliser ALTER TABLEavec succès et modifier mes tables.

C'est ce que j'ai fait pour résoudre mon problème. J'ai testé dans MySQL 5.7 local ubuntu 18.04.

set global sql_mode="NO_ENGINE_SUBSTITUTION";

Avant d'exécuter cette requête globalement, j'ai ajouté un fichier cnf dans le répertoire /etc/mysql/conf.d . Le nom du fichier cnf est mysql.cnf et codes

[mysqld]
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Puis je redémarre mysql

sudo service mysql restart

J'espère que cela peut aider quelqu'un.

C'est incroyablement moche, mais cela a aussi résolu le problème rapidement pour moi. Votre table a besoin d'une clé unique que vous utiliserez pour réparer les colonnes corrompues. Dans cet exemple, la clé primaire est appelée «id» et la colonne d'horodatage interrompue est appelée «BadColumn».

1. Sélectionnez les ID des colonnes contaminées.

   select id from table where BadColumn='0000-00-00 00:00:00'

2. Collectez les ID dans une chaîne délimitée par des virgules. Exemple: 1, 22, 33. J'ai utilisé un wrapper externe pour cela (un script Perl) pour les recracher rapidement.

3. Utilisez votre liste d'identifiants pour mettre à jour les anciennes colonnes avec une date valide (1971 à 2038).

   update table set BadColumn='2000-01-01 00:00:00' where id in (1, 22, 33)

Ma solution

SET sql_mode='';
UPDATE tnx_k2_items
SET created_by = 790
, modified = '0000-00-00 00:00:00'
, modified_by = 0

Au lieu de

UPDATE your_table SET your_column = new_valid_value where your_column = '0000-00-00 00:00:00';

Utilisation

UPDATE your_table SET your_column = new_valid_value where your_column = 0;

Si vous entrez les données manuellement, vous pouvez envisager de supprimer les valeurs et les zéros du TIMESTAMP (6) .000000 afin qu'il devienne TIMESTAMP. Cela a bien fonctionné avec moi.