web-dev-qa-db-fra.com

Erreur mysql datetime DEFAULT CURRENT_TIMESTAMP

1. Lorsque j'ai exécuté cette syntaxe MYSQL sur Windows, elle a fonctionné correctement.

CREATE TABLE New
(
id bigint NOT NULL AUTO_INCREMENT,
timeUp datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id)
)

Mais quand j'ai essayé d'exécuter ce code sous Linux, j'ai eu une erreur

 #1067 - Invalid default value for 'time'

2. Sous Windows, la casse n'est pas sensible, par exemple. Le nouveau et le nouveau sont considérés comme identiques. Mais sous Linux, le cas est sensible.

Configuration de Linux

MySQL 5.5.33, phpMyAdmin 4.0.5 et PHP 5.2.17

Configuration de Windows

MySql: 5.6.11, phpMyAdmin 4.0.4.1 PHP: 5.5.0

Est-ce leur moyen de les rendre communs aux deux systèmes. Ou toute autre approche. Merci d'avoir lu.

phpmysqllinuxwindows
12
Johny Pie

Le DEFAULT CURRENT_TIMESTAMP la prise en charge d'un DATETIME (type de données) a été ajoutée dans MySQL 5.6.

Dans les versions 5.5 et antérieures, cela ne s'appliquait qu'aux colonnes TIMESTAMP (type de données).

Il est possible d'utiliser un BEFORE INSERT déclencheur en 5.5 pour affecter une valeur par défaut à une colonne.

 DELIMITER $$

 CREATE TRIGGER ...
 BEFORE INSERT ON mytable
 FOR EACH ROW
 BEGIN
    IF NEW.mycol IS NULL THEN
       SET NEW.mycol = NOW();
    END IF;
 END$$

La sensibilité à la casse (des requêtes par rapport aux valeurs stockées dans les colonnes) est due à collation utilisé pour la colonne. Les classements se terminant par _ci ne sont pas sensibles à la casse. Par exemple latin1_swedish_ci n'est pas sensible à la casse, mais latin1_general_cs est sensible à la casse.

La sortie de SHOW CREATE TABLE foo affichera le jeu de caractères et le classement des colonnes de type de caractère. Ceci est spécifié au niveau d'une colonne. Le "défaut" spécifié au niveau de la table s'applique aux nouvelles colonnes ajoutées à la table lorsque la nouvelle définition de colonne ne spécifie pas de jeu de caractères.

MISE À JOUR

Kaii a souligné que ma réponse concernant la "respect de la casse" concerne les valeurs stockées dans les colonnes et si les requêtes renverront une valeur à partir d'une colonne contenant une valeur de "New" sera retourné avec un prédicat comme "t.col = 'new'".

Voir la réponse de Kaii concernant identifiants (par exemple les noms de table) traités différemment (par défaut) sous Windows que sous Linux.

32
spencer7593

Comme le DEFAULT CURRENT_TIMESTAMP la question est déjà répondue, je ne répondrai qu'à la différence de sensibilité à la casse dans les noms de table entre windows et linux.

Sous Windows, les systèmes de fichiers ne respectent pas la casse par défaut.
Mais sous Linux et autres * NIX comme les systèmes d'exploitation, ils sont sensibles à la casse par défaut.

La raison pour laquelle vous obtenez une différence de comportement ici est le système de fichiers, car chaque table est créée en tant que fichier distinct et le système de fichiers gère la sensibilité à la casse pour vous.

MySQL a un paramètre pour remplacer ce comportement:

Par exemple, sous Unix, vous pouvez avoir deux tables différentes nommées my_table et MY_TABLE, mais sous Windows, ces deux noms sont considérés comme identiques. Pour éviter les problèmes de transfert de données résultant de la casse des noms de base de données ou de table, vous avez deux options:

  • Utilisation lower_case_table_names=1 sur tous les systèmes. Le principal inconvénient est que lorsque vous utilisez SHOW TABLES ou SHOW DATABASES, vous ne voyez pas les noms dans leur boîte aux lettres d'origine.

  • Utilisation lower_case_table_names=0 sur Unix et lower_case_table_names=2 sous Windows. Cela préserve la casse des noms de base de données et de table. L'inconvénient de cela est que vous devez vous assurer que vos instructions se réfèrent toujours à vos noms de base de données et de table avec la casse correcte sous Windows. Si vous transférez vos relevés vers Unix, où la casse est importante, ils ne fonctionnent pas si la casse est incorrecte.

    Exception: Si vous utilisez des tables InnoDB et que vous essayez d'éviter ces problèmes de transfert de données, vous devez définir lower_case_table_names=1 sur toutes les plates-formes pour forcer la conversion des noms en minuscules.

[...]
Pour éviter les problèmes causés par de telles différences, , il est préférable d'adopter une convention cohérente, telle que toujours créer et se référer à des bases de données et des tables en utilisant des noms en minuscules . Cette convention est recommandée pour une portabilité maximale et une facilité d'utilisation.

Ceci est un extrait du manuel MySQL sur la sensibilité à la casse des identifiants

3
Kaii

si vous voulez que l'heure par défaut soit remplacée par timestamp dans votre type de données,

le datetime va afficher l'entrée utilisateur de la table ...

http://dev.mysql.com/doc/refman/5.0/en/timestamp-initialization.html

http://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html

1
jmail