Erreur MySQL datetime DEFAULT CURRENT_TIMESTAMP

1.
Quand j'ai couru cette syntaxe de MYSQL sur windows, il a couru 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 sur Linux j'ai eu une erreur

 #1067 - Invalid default value for 'time'

2.
Sous windows, le cas n'est pas sensible, par exemple. De nouveau et de nouveau les deux sont considérés comme identiques. Mais sous linux, l'affaire est sensible.

Configuration de Linux

MySQL 5.5.33 , phpMyAdmin 4.0.5 et PHP version 5.2.17

De Configuration de Windows

MySql: article 5.6.11, phpMyAdmin 4.0.4.1 PHP : 5.5.0

Est leurs façon de faire commune pour les deux systèmes. Ou de toute autre approche. Merci pour la lecture.

source d'informationauteur Johny Pie

28

La DEFAULT CURRENT_TIMESTAMP de soutien pour un DATETIME (datatype) a été ajoutée en MySQL 5.6.

En 5.5 et versions antérieures, cette applique uniquement à TIMESTAMP (datatype) colonnes.

Il est possible d'utiliser un BEFORE INSERT déclencheur de 5,5 à attribuer une valeur par défaut pour 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$$
```
Sensibilité à la casse (des requêtes sur les valeurs stockées dans des colonnes) est due à la collation utilisé pour la colonne. Les classements se terminant en _ci sont insensibles à la casse. Par exemple latin1_swedish_ci est insensible à la casse, mais latin1_general_cs est sensible à la casse.

La sortie de SHOW CREATE TABLE foo montrera le jeu de caractères et collation pour le type de caractère colonnes. C'est spécifiée au niveau des colonnes. Le "par défaut", a précisé au niveau de la table s'applique pour les nouvelles colonnes sont ajoutées à la table lorsque la nouvelle définition de la colonne de ne pas spécifier un characterset.

Mise à JOUR

Kaii a souligné que ma réponse au sujet "de la casse" traite des valeurs stockées dans les colonnes, et si les requêtes renvoie la valeur d'une colonne contenant une valeur de "New" sera retourné avec un prédicat comme "t.col = 'new'".

Voir Kaii de réponse quant à identificateurs (par exemple, les noms de table) d'être traités différemment (par défaut) sur Windows que sur Linux.
3

Comme le DEFAULT CURRENT_TIMESTAMP question est déjà répondu, je vais seulement répondre à la casse de décalage dans les noms de table entre windows et linux.

Sur Windows, les systèmes de fichiers sont par défaut pas sensible à la casse.

Mais sur Linux et les autres UNIX comme système d'Exploitation, ils sont sensibles à la casse par défaut.

La raison pourquoi vous obtenez une erreur dans le comportement ici est le système de fichiers, comme chaque table est créée dans un fichier séparé et le système de fichiers gère la casse pour vous.

MySQL a un paramètre pour ignorer ce comportement:
Par exemple, sous Unix, vous pouvez avoir deux tables différentes nommé my_table
et MY_TABLE, mais sur Windows ces deux noms sont considérés comme identiques.
Pour éviter les problèmes de transfert de données découlant de lettercase de base de données ou
les noms de table, vous avez deux options:
- Utilisation lower_case_table_names=1 sur tous les systèmes. Le principal inconvénient de cette est que lorsque vous utilisez SHOW TABLES ou SHOW DATABASESvous ne
  ne pas voir les noms dans leur origine lettercase.
- Utilisation lower_case_table_names=0 sur Unix et lower_case_table_names=2 sur Windows. Cela préserve la lettercase de base de données et les noms de table.
  L'inconvénient de cette est que vous devez vous assurer que vos déclarations
  consultez toujours votre base de données et les noms de table avec le bon
  lettercase sur Windows. Si vous transférez vos déclarations Unix, où
  lettercase est important, ils ne fonctionnent pas si le lettercase est
  incorrect.
  
  Exception: Si vous utilisez les tables MyISAM 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 à force de noms convertis en minuscules.
[...]

Pour éviter les problèmes causés par ces différences,
il est préférable d'adopter une convention cohérente, comme toujours, la création d'
et se référant à des bases de données et des tables à l'aide de minuscules les noms. Cette
la convention est recommandé pour un maximum de portabilité et de facilité d'utilisation.
Ceci est un extrait de l' Manuel MySQL sur le cas de la sensibilité des identificateurs
0

si tu veut délai par défaut doivent changer pour timestamp dans votre type de données,

la datetime va afficher l'entrée de l'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

Vous devez vous connecter pour publier un commentaire.