Erreur mysql datetime DEFAULT CURRENT_TIMESTAMP

si vous souhaitez définir l'heure par défaut, vous devez passer à timestamp dans votre type de données,

le datetime va afficher l'entrée utilisateur du tableau...

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

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

Comme le DEFAULT CURRENT_TIMESTAMP la question a déjà une réponse, je ne répondrai qu'à l'incompatibilité de sensibilité à la casse dans les noms de table entre Windows et Linux.

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

La raison pour laquelle vous obtenez une incompatibilité de comportement ici est le système de fichiers, car chaque table est créée en tant que fichier séparé 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.

• Utilisez 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 casse d'origine.

• Utilisez lower_case_table_names=0 sous Unix et lower_case_table_names=2 sur Windows. Cela préserve la casse des noms de base de données et de table. L'inconvénient est que vous devez vous assurer que vos instructions font toujours référence à vos noms de base de données et de table avec la casse correcte sous Windows. Si vous transférez vos instructions vers Unix, où la casse est importante, elles ne fonctionneront 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 plateformes 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, comme toujours créer et faire référence aux bases de données et aux tables en utilisant des noms en minuscules . Cette convention est recommandée pour une portabilité et une facilité d'utilisation maximales.

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

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

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

Il est possible d'utiliser un BEFORE INSERT trigger en 5.5 pour attribuer 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 sur des valeurs stockées dans des colonnes) est due au collation utilisé pour la colonne. Classements se terminant par _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 affichera le jeu de caractères et le classement pour les colonnes de type de caractères. Ceci est spécifié au niveau de chaque colonne. La "valeur par défaut" spécifiée 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 "sensibilité à la casse" traite des 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 les identifiants (par exemple, les noms de table) étant gérés différemment (par défaut) sous Windows que sous Linux.