Problème lors de l'insertion de la valeur d'horodatage dans MySQL

Question

Il existe d'autres questions où les utilisateurs ont des problèmes avec l'horodatage étant tous des zéros. Je les ai vérifiés et ce n'est pas un doublon.

Je déclare une table comme ceci:

CREATE TABLE `my_db`.`my_table` (
    `time_stamp` timestamp NOT NULL, 
    `author` varchar() NOT NULL, 
    `text` text NOT NULL, 
    `md5` int(11) NOT NULL, 
    PRIMARY KEY (`time_stamp`) 
) ; 

J'ai aussi une deuxième table qui aura un horodatage comme clé primaire et ils devraient avoir la même valeur.

Codage en Delphi, j'utilise SELECT CURRENT_TIMESTAMP qui renvoie quelque chose comme '19/6/2010 4:56:17 AM' que j'utilise ensuite dans une instruction INSERT. L'INSERT réussit, mais l'horodatage est tous des zéros.

Qu'est-ce que je fais mal?

Voici le code INSERT:

sqlCommand := 'INSERT INTO my_db.my_table(time_stamp, author, text, md5) VALUES ("' 
        + timestamp + 
        '", "mawg", ' + 
        '"Hello, world"' + 
        0 + 
        '");'; 
    Result := DoSQlCommandWithNoResultSet(sqlCommand, AdoConnection); 

insertion sera très faible taux, une entrée toutes les quelques semaines ou quelques mois peut-être, alors je suis heureux avec horodatage comme clé primaire. Je garde des «versions» des choses, donc l'horodatage a du sens pour moi. Je prie de penser que c'est un problème d'ADO, bien que je m'attendrais à ce que ADO "passe juste". Je ne vois pas d'autre solution. Dans une console, la sortie est "correcte", mais lorsqu'elle est exécutée via ADO dans Delphi alors elle est erronée

Puis-je spécifier à MySQL comment il doit formater ses dates?

Answer 1

Après avoir examiné la documentation MySQL, il semble que si votre valeur timestamp est formaté de manière incorrecte, il cause normalement l'horodatage d'être '0000-00-00 00:00:00'. Dans tous les cas, vous n'avez pas besoin de spécifier une valeur d'horodatage — qui est l'avantage de TIMESTAMP sur DATETIME. Et même si vous l'avez fait, vous pouvez simplement le définir sur NOW() au lieu d'exécuter une instruction inutile SELECT.

Edit:

De plus, je sais que vous avez dit que vous pensiez que cela à travers, mais vous avez envisagé l'heure d'été? Cela peut entraîner la même horodatage pour deux enregistrements lorsque l'horloge est remise à l'automne.

Edit 2:

K, je ne sais pas pourquoi je ne l'ai pas attrapé plus tôt, mais ce format d'horodatage fourni est incorrect. Essayez d'insérer un horodatage valide comme '2010/06/19 4:56:17'. MySQL a analysé les valeurs de temps, mais il doit toujours être year-month-date et hour-minute-seconds.

Edit 3:

D'accord, il semble y avoir un peu de confusion sur cela, alors je vais après cette citation de MySQL 5.0 page doc sur le DATETIME format:

pour les valeurs spécifiées comme les chaînes qui incluent des délimiteurs de partie de date, il n'est pas nécessaire de spécifier deux chiffres pour les valeurs de mois ou de jour qui sont inférieures à 10. '1979-6-9' est identique à '1979-06-09'. De même, pour les valeurs spécifiées comme des chaînes qui incluent des délimiteurs de partie temporelle, il n'est pas nécessaire de spécifier deux chiffres pour les valeurs d'heure, de minute ou de seconde inférieures à 10. '1979-10-30 1: 2: 3' est la même comme '1979-10-30 01:02:03'.

Answer 2

Jetez un oeil à MySQL date functions. Ils sont très étendus et permettent une grande flexibilité. En plus de tout cela, je recommande de repenser la structure de votre table. Un timestap en tant que clé primaire n'est pas exactement ce que vous voulez. Lorsque vous avez un trafic élevé, il peut arriver que l'horodatage soit le même. De plus, si vous sauvegardez 2 enregistrements ou plus à la suite, l'horodatage sera le même. En outre, votre colonne MD5 est définie sur int (11). Les hachages MD5 utilisent des caractères mixtes, donc je préfère aller avec varchar (32).

CREATE TABLE `my_db`.`my_table` ( 
    `id` int(11) NOT NULL, 
    `timestamp` timestamp NOT NULL, 
    `author` varchar(100) NOT NULL, 
    `text` text NOT NULL, 
    `md5` varchar(32) NOT NULL, 
PRIMARY KEY (`id`) 
) ; 

Answer 3

AFAIR 19/6/2010 4:56:17 AM est pas un format de date valide pour les types de date MySQL. Vous devez le convertir en 2010-06-19 04:56:14 (voir doc).