web-dev-qa-db-fra.com

Valeur de date/heure incorrecte Numéro d'erreur de base de données: 1292

Valeur date/heure incorrecte 0000-00-00 00:00:00 +0000 Numéro d'erreur base de données: 1292

Salut tout le monde, je rencontre un problème de mise à niveau du serveur par mon hébergeur et j'essaie de comprendre ce qui se passe pour pouvoir résoudre le problème.

Mon serveur a récemment été mis à niveau vers la version serveur: 5.6.17 et j'obtiens des erreurs partout disant que ma valeur datetime est incorrecte?

Il semble que ce soit +0000 à la fin de la date et l'heure, mais je ne sais pas pourquoi. Auparavant, cela fonctionnait parfaitement sur 5.5, mais une mise à jour récente a affecté le fonctionnement de mes horodatages.

Error Number: 1292

Incorrect datetime value: '2014-04-02 08:49:43 +0000' for column 'created' at row 1

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')

Si je modifie cette requête SQL sans +0000 cela fonctionne?

Cela affecte tout ce qui est un type de DATETIME sur ma table.

Quelqu'un a-t-il eu un problème similaire et quelle est la solution pour que cela fonctionne? Pour le moment, je vais devoir modifier toutes mes fonctions PHP pour faire écho à la date/heure plutôt que de m'appeler NOW () sur la chaîne de requête.

phpmysqldatabasedatetime
14
Luke O'Regan

Après la mise à niveau vers MySQL 5.7, j'ai découvert que cette erreur commençait à se produire de manière aléatoire, même lorsque je ne fournissais pas de date dans la requête.

Cela semble être dû au fait que les versions précédentes de MySQL prenaient en charge des dates telles que 0000-00-00 00:00:00 (par défaut). Cependant, 5.7.4 a apporté certaines modifications au paramètre NO_ZERO_DATE. Si vous avez toujours d'anciennes données lorsque vous utilisez une version plus récente de MySQL, des erreurs aléatoires peuvent survenir.

J'avais besoin d'effectuer une requête comme celle-ci pour réinitialiser toutes les dates zéro à une autre date.

# 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';

Sinon, vous pourrez peut-être ajuster le paramètre NO_ZERO_DATE, mais notez ce que la documentation en dit:

Le mode NO_ZERO_DATE détermine si le serveur autorise ou non '0000-00-00' comme date valide. Son effet dépend également de l'activation du mode SQL strict.

  • Si ce mode n'est pas activé, '0000-00-00' est autorisé et les insertions ne produisent aucun avertissement.

  • Si ce mode est activé, '0000-00-00' est autorisé et les insertions génèrent un avertissement.

  • Si ce mode et le mode strict sont activés, '0000-00-00' n'est pas autorisé et les insertions génèrent une erreur, sauf si IGNORE est également indiqué. Pour INSERT IGNORE et UPDATE IGNORE, '0000-00-00' est autorisé et les insertions génèrent un avertissement.

Depuis MySQL 5.7.4, NO_ZERO_DATE est obsolète. Dans MySQL 5.7.4 à 5.7.7, NO_ZERO_DATE ne fait rien lorsqu'il est nommé explicitement. Au lieu de cela, son effet est inclus dans les effets du mode SQL strict. Dans MySQL 5.7.8 et les versions ultérieures, NO_ZERO_DATE a un effet lorsqu'il est nommé explicitement et ne fait pas partie du mode strict, comme avant MySQL 5.7.4. Cependant, il doit être utilisé conjointement avec le mode strict et est activé par défaut. Un avertissement se produit si NO_ZERO_DATE est activé sans activer également le mode strict ou inversement. Pour plus d'informations, reportez-vous à la section Modifications du mode SQL dans MySQL 5.7.

Étant donné que NO_ZERO_DATE est obsolète, il sera supprimé dans une version ultérieure de MySQL en tant que nom de mode distinct et son effet sera inclus dans les effets du mode SQL strict.

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

10
Simon East

Réponse courte - NOW() dans votre requête devrait parfaitement fonctionner avec une colonne MySQL DATETIME.

Réponse plus longue - Je ne suis pas sûr de savoir comment vous avez déjà vu +0000 fonctionner. La colonne DATETIME est au format 'YYYY-MM-DD HH:MM:SS'. En ce qui concerne les différences de fuseaux horaires, vous devez généralement les gérer par programme. MySQL convertit les heures locales en heure UTC et inversement lors du stockage et de la récupération des données TIMESTAMP - mais ne le fait pas avec DATETIME ou d'autres colonnes Date/Heure.

5
Ragdata

Valeur de date/heure incorrecte Numéro d'erreur de base de données: 1292

Le type de données TIMESTAMP est utilisé pour les valeurs contenant des parties de date et d'heure. TIMESTAMP a une plage de '1970-01-01 00:00:01' UTC à '2038-01-19 03:14:07' UTC.

Le type DATETIME est utilisé pour les valeurs contenant des parties de date et d'heure. MySQL récupère et affiche les valeurs DATETIME au format 'YYYY-MM-DD HH:MM:SS'. La plage prise en charge est '1000-01-01 00:00:00' to '9999-12-31 23:59:59'.

vous devez utiliser ce type dans: format DateTime

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/en/date-and-time-types.html

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

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

mise à jour: 1

vous devriez supprimer la space comme votre code '2014-04-02 08:49:43 +0000' et changer le code comme '2014-04-02 08:49:43+0000' car la requête complète est la suivante:

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')

regardez ici: http://sqlfiddle.com/#!2/a2581/23099

4
jmail

Ok, j'avais donc la même erreur. Pour résoudre ce problème, j'ai utilisé ces lignes de code pour interroger la base de données avec laquelle je rencontrais des problèmes:

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

La première ligne de code (SELECT) indique le réglage actuel pour "SESSION" et "GLOBAL". Une fois que vous définissez les deux chaînes vides et que vous exécutez à nouveau la sélection, elles ne doivent rien renvoyer (être vides).

Vous devrez peut-être aussi utiliser SET SESSION sql_mode = ''; mais cela résout le problème pour moi. Fondamentalement, l’un des paramètres de cette opération était de modifier la façon dont la date entrait dans la base de données (je l’obtenais au format AAAA-MM-JJ HH: MM: SS AM/PM). Supprimer NO_ZERO_IN_DATE et l’option autre date ne m’a pas aidé.

Mon site fonctionne comme il est censé le faire maintenant. Espérons que cela aide.

4
JedtheMarine

Le fichier my.cnf d'origine avait sql_model défini comme suit:

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

J'ai essayé de supprimer NO_ZERO_IN_DATE et NO_ZERO_DATE mais cela n'a eu aucun effet. Mais si je supprimais tous les termes (sql_mode vide), l'erreur disparaissait.

Je suis revenu à sql_mode original et j'ai pensé que je supprimerais les termes 1 à 1 pour voir lequel était la cause. La première tentative a été de supprimer STRICT_TRANS_TABLES:

sql_mode=NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Pas d'erreur. Il semble donc que STRICT_TRANS_TABLES en soit la cause.

0
RDVS