Valeur par défaut non valide pour le champ d'horodatage 'create_date'

190

J'ai l'instruction de création SQL suivante

mysql> CREATE  TABLE IF NOT EXISTS `erp`.`je_menus` (
    ->   `id` INT(11) NOT NULL AUTO_INCREMENT ,
    ->   `name` VARCHAR(100) NOT NULL ,
    ->   `description` VARCHAR(255) NOT NULL ,
    ->   `live_start_date` DATETIME NULL DEFAULT NULL ,
    ->   `live_end_date` DATETIME NULL DEFAULT NULL , 
    ->   `notes` VARCHAR(255) NULL ,
    ->   `create_date` TIMESTAMP NOT NULL DEFAULT  '0000-00-00 00:00:00',
    ->   `created_by` INT(11) NOT NULL ,
    ->   `update_date` TIMESTAMP NOT NULL DEFAULT  CURRENT_TIMESTAMP  ,
    ->   `updated_by` INT(11) NOT NULL , 
    ->   `status` VARCHAR(45) NOT NULL ,
    ->   PRIMARY KEY (`id`) ) 
    -> ENGINE = InnoDB;

donnant l'erreur suivante

ERROR 1067 (42000): Invalid default value for 'create_date'

Quelle est l'erreur ici?

Robert
la source
Je ne vois rien de mal avec votre requête et cela fonctionne sur la communauté 5.1.50 que je viens de tester.
Jaspreet Chahal
La requête me convient également.
Shakti Singh
Pas sûr, mais donnez un nom différent à ce champ et essayez?
Naveen Kumar
J'utilise la communauté mysql 5.1.56 dans ubuntu 10.04. et ne fonctionne pas
robert
5
La date sans zéro nécessite une date. Utilisez «1970-01-01 00:00:01». [tiré d'ici] [1] [1]: dba.stackexchange.com/questions/6171/…
Jadeye

Réponses:

181

Cela est dû au mode SQL du serveur - NO_ZERO_DATE .

D'après la référence: NO_ZERO_DATE- En mode strict, ne pas autoriser '0000-00-00'comme date valide. Vous pouvez toujours insérer des dates nulles avec l' option IGNORE . Lorsqu'il n'est pas en mode strict, la date est acceptée mais un avertissement est généré.

Devart
la source
19
comment donner l'option Ignorer?
robert
9
Vous ne pouvez pas ignorer cette option. Ceci est une option de serveur. Si vous avez accès à my.ini (fichier de configuration mysql), supprimez NO_ZERO_DATE de l'option sql-mode et redémarrez le serveur.
Devart
9
Pour vérifier cette option - exécutez SHOW VARIABLES LIKE 'sql_mode'
Devart
6
J'ai généré le script à l'aide de mysql workbench. Dans le script, sql_mode est défini sur traditional. Si je supprime le traditionnel, le script fonctionne.
robert
17
Dans les préférences de MySQL Workbench, allez dans l'onglet 'Modèle: MySQL'. Il a défini 'SQL_MODE à utiliser dans les scripts générés' à "STRICT_TRANS_TABLES, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION" Cela résout le problème pour de bon.
sgtdck
147

Si vous avez généré le script à partir de l'atelier MySQL.

La ligne suivante est générée

SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';

Supprimez TRADITIONAL du SQL_MODE, puis le script devrait fonctionner correctement

Sinon, vous pouvez définir SQL_MODE comme Autoriser les dates non valides

SET SQL_MODE='ALLOW_INVALID_DATES';
Pankaj Shrestha
la source
1
Cela m'a fait gagner du
5
Ahhh merci. SET SQL_MODE = 'ALLOW_INVALID_DATES'; a sauvé la vie. J'ai eu ce problème lorsque je tentais de migrer un site wordpress vers un autre serveur (à la fois local) et cela ne me permettait pas d'importer les données de la base de données en raison de cette erreur, même s'il n'y avait pas de lignes dans les tables avec cette erreur.
mikato
A travaillé comme un charme! Merci.
moreirapontocom
56

TIMESTAMP a une plage de '1970-01-01 00:00:01' UTC à '2038-01-19 03:14:07' UTC (voir doc ). La valeur par défaut doit être comprise dans cette plage.

Autre comportement étrange et apparenté:

CREATE TABLE tbl1 (
    ts TIMESTAMP);  
Query OK, 0 rows affected (0.01 sec)

CREATE TABLE tbl2 (
    ts TIMESTAMP,
    ts2 TIMESTAMP);
ERROR 1067 (42000): Invalid default value for 'ts2'

CREATE TABLE tbl3 (
    ts TIMESTAMP,
    ts2 TIMESTAMP DEFAULT '1970-01-01 00:00:01');
Query OK, 0 rows affected (0.01 sec)

Remarque latérale, si vous souhaitez insérer des NULLS:

CREATE TABLE tbl4 (
    ts TIMESTAMP NULL DEFAULT NULL);
Bret VvVv
la source
1
Cela m'arrive. Qu'est-ce qui se passe? ts2 n'est même pas "NOT NULL" ...!
PedroD
2
Peut-être parce que "Si vous ne définissez pas de valeur pour la première colonne TIMESTAMP d'une table, MariaDB lui attribuera automatiquement la date et l'heure actuelles lors de l'exécution d'une requête UPDATE ou INSERT sur la ou les lignes en question." - MariaDB Docs
jsphpl
1
J'aime l'utilisation de column_name TIMESTAMP DEFAULT NOW(). Peut-être ne convient pas à toutes les situations, mais je pensais que je partagerais car je traitais aussi de cela.
DeezCashews
1
nom_colonne TIMESTAMP DEFAULT '1970-01-01 00:00:01' a fait l'affaire pour moi. Merci!
metafa
42

Dans ubuntu desktop 16.04, j'ai fait ceci:

  1. ouvrir le fichier: /etc/mysql/mysql.conf.d/mysqld.cnfdans un éditeur de votre choix.

  2. Cherchez:, sql_modece sera quelque part sous [mysqld].

  3. et réglez sql_modesur ce qui suit:

    NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

  4. Enregistrez puis redémarrez le service mysql en faisant:

    sudo service mysql restart

Mubashar Abbas
la source
9
Cela a aidé, sauf que le sql_moden'était pas là pour mon instance de mySQL sur ubuntu16.04. J'ai dû ajouter une entrée pour cela dans le fichier, en supprimant le "NO_ZERO_DATE". Donc, voici à quoi il ressemble maintenant: #Adding la ligne ci - dessous pour se débarrasser de no_zero_date sql_mode = ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_SUBSTITUTION
OK999
vous avez raison .. J'ai ajouté cela plus tôt pour désactiver le mode strict .. et quand je l'ai édité pour ce problème particulier, l' sql_modeentrée était déjà là.
Mubashar Abbas
Est-ce un bug? CURRENT_TIMESTAMP ne doit jamais renvoyer "0000-00-00 00:00:00", ou je me trompe? Pourquoi devrais-je changer les paramètres de mysqld?
letsjump
@letsjump car quelqu'un n'a pas configuré correctement votre serveur mysql. Je rencontre ce problème avec une base de données que j'ai importée. la valeur par défaut de l'horodatage dans une colonne n'est pas une valeur d'horodatage valide. le correctif REEL est de mettre à jour l'horodatage par défaut à quelque chose de valide comme 1970 - la première date disponible. La solution temporaire consiste à désactiver la vérification dans la base de données.
anon58192932
10

Sous OS X , installez mysql depuis Homebrew , les variables système en fonction de ses valeurs par défaut compilées. La solution consiste à supprimer "NO_ZERO_DATE" des variables système "sql_mode".

Veuillez garder à l'esprit que la portée implique.

Si vous souhaitez affecter uniquement dans votre session, veuillez utiliser "@@session", par exemple:

SET @@session.sql_mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION".

Dans ce cas, cela n'affectera pas une fois votre session terminée ou votre modification. Cela n'a pas d'effet sur les autres sessions.

Si vous souhaitez affecter tous les clients, veuillez utiliser "@@global", par exemple:

SET @@global.sql_mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION".

Dans ce cas, cela n'affecte que les clients qui se connectent après la modification (n'affecte pas tous les clients actuels) et ne fonctionnera pas une fois le serveur fermé.

Joy Zhu
la source
8

J'ai pu résoudre ce problème sur OS X en installant MySQL à partir de Homebrew

brew install mysql

en ajoutant ce qui suit à /usr/local/etc/my.cnf

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

et redémarrer MySQL

brew tap homebrew/services
brew services restart mysql
dgitman
la source
8

J'ai eu un problème similaire avec MySQL 5.7 avec le code suivant:

`update_date` TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP

J'ai corrigé en utilisant ceci à la place:

`update_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

pyb
la source
2
Je pense que c'est en fait la meilleure option pour quand il est logique de passer par défaut au courant, cela n'aurait cependant pas de sens pour l'horodatage de naissance - juste à titre d'exemple.
meow
8

Pour éviter ce problème, vous devez supprimer NO_ZERO_DATEde la configuration du mode mysql.

  1. Accédez à «phpmyadmin».
  2. Une fois phpmyadmin chargé, cliquez sur l'onglet «variables».
  3. Recherchez 'sql mode'.
  4. Cliquez sur l'option Modifier et supprimez NO_ZERO_DATE(et sa virgule de fin) de la configuration.

C'est un problème très courant dans l'environnement local avec wamp ou xamp.

Antonio Reyes
la source
Quand je redémarre Mamp, ils réapparaissent
The Sloth
8

Définissez simplement les lignes suivantes en haut de votre fichier SQL de base de données.

SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
SET time_zone = "+00:00";

Ça marche pour moi.

Ashish Odich
la source
2

Pour désactiver le mode SQL strict

Create disable_strict_mode.cnf file at /etc/mysql/conf.d/

Dans le fichier, entrez ces deux lignes:

[mysqld]
sql_mode=IGNORE_SPACE,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Enfin, redémarrez MySQL avec cette commande:

sudo service mysql restart
Jatin Bhatti
la source
1

Vous voudrez peut-être examiner le paramètre de fuseau horaire sur l'instance MySql:

mysql> show variables like 'time_zone';
+---------------+--------+
| Variable_name | Value  |
+---------------+--------+
| time_zone     | SYSTEM |
+---------------+--------+

dans mon cas, j'ai réalisé que le système sous-jacent avait son fuseau horaire réglé sur BST plutôt que sur UTC, et donc dans la table de création, la valeur par défaut de `` 1970-01-01 00:00:01 '' était forcée en arrière d'une heure, ce qui entraînait une valeur d'horodatage non valide.

Pour moi, je voulais en fait que le fuseau horaire de la machine soit réglé sur UTC, et cela m'a arrangé. Comme j'utilisais Centos / 7, j'ai simplement fait

# timedatectl set-timezone UTC

et tout redémarré.

Robert Hook
la source
1

Les valeurs par défaut doivent commencer à partir de l'an 1000.

Par exemple,

ALTER TABLE mytable last_active DATETIME DEFAULT '1000-01-01 00:00:00'

J'espère que cela aide quelqu'un.

David Beckwith
la source
1

Change ça:

`create_date` TIMESTAMP NOT NULL DEFAULT  '0000-00-00 00:00:00',
`update_date` TIMESTAMP NOT NULL DEFAULT  CURRENT_TIMESTAMP  ,

Aux suivants:

`create_date` TIMESTAMP NOT NULL DEFAULT  CURRENT_TIMESTAMP ,
`update_date` TIMESTAMP NOT NULL DEFAULT  CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ,
荒木 知
la source
1
De l'avis: Bonjour, ne répondez pas uniquement avec le code source. Essayez de fournir une belle description du fonctionnement de votre solution. Voir: Comment écrire une bonne réponse? . Merci
sɐunıɔ ןɐ qɐp
S'il s'agit d'un site WordPress, veuillez ne pas mettre à jour les tableaux Core WordPress. De nombreux plugins s'attendent à une valeur de zeores, donc WordPress ne peut pas modifier cette valeur par défaut pour des raisons héritées qui casseraient les plugins. Prise en charge des threads Wordpress et Wordpress . Changer la structure de la base de données sans familiarité avec le code en se basant sur les valeurs par défaut peut entraîner des bogues inquiétants. Bien que cela puisse fonctionner comme une solution dans de nombreux cas, cela pourrait faire des ravages dans d'autres. Pas une solution universelle.
SherylHohman le
0

Vous pouvez simplement changer ceci:

`create_date` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',

À quelque chose comme ça:

`create_date` TIMESTAMP NOT NULL DEFAULT '2018-04-01 12:00:00',
Lucas Bustamante
la source
0

Vous pouvez simplement changer ceci:

create_date datetime NOT NULL DEFAULT '0000-00-00 00:00:00',

À quelque chose comme ça:

create_date varchar (80) NOT NULL DEFAULT '0000-00-00 00:00:00',

Ankush Singhal
la source
0

J'essaie de définir le type de colonne comme «horodatage» et cela fonctionne pour moi.

mzzhaaf
la source