Mawg
Mawg

Reputation: 40140

Issue inserting timestamp value in MySQL

There are some other questions where people have problems with timestamp being all zeros. I have checked them and this is not a duplicate.

I declare a table like this:

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`)
) ;

I also have a second table which will have a timestamp as primary key and they should have the same value.

Coding in Delphi, I use SELECT CURRENT_TIMESTAMP which returns something like '19/6/2010 4:56:17 AM' which I then use in an INSERT statement. The INSERT succeeds, but the timestamp is all zeros.

What am I doing wrong?

Here's the INSERT code:

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

Insertion will be extremely low rate, one entry every few weeks or maybe months, so I am happy with timestamp as primary key. I am keeping "versions" of things, so timestamp makes sense to me.

I am begging to think that this is an ADO problem, although I would expect ADO to just "pass through". I don't see any other solution. In a console, the output is "correct", but when run through ADO in Delphi then it is wrong

Can I specify to MySQL how it ought to format its dates?

Upvotes: 1

Views: 2582

Answers (3)

Lèse majesté
Lèse majesté

Reputation: 8045

After reviewing the MySQL documentation, it appears that if your timestamp value is incorrectly formatted, it would normally cause the timestamp to be '0000-00-00 00:00:00'. In any case, you don't need to specify a timestamp value—that's the benefit of TIMESTAMP over DATETIME. And even if you did, you can simply set it to NOW() instead of running an unnecessary SELECT statement.

Edit:

Also, I know you said you thought this through, but have you considered daylight savings time? This could cause two records to have the same timestamp when the clock is set back during autumn.

Edit 2:

K, I don't know why I didn't catch this earlier, but that timestamp format you gave is incorrect. Try inserting a valid timestamp like '2010/06/19 4:56:17'. MySQL has pretty relaxed parsing of date & time values, but it always has to be year-month-date and hour-minute-seconds.

Edit 3:

Alright, there seems to be a little confusion over this, so I'm gonna post this quote from the MySQL 5.0 doc page on the DATETIME format:

For values specified as strings that include date part delimiters, it is not necessary to specify two digits for month or day values that are less than 10. '1979-6-9' is the same as '1979-06-09'. Similarly, for values specified as strings that include time part delimiters, it is not necessary to specify two digits for hour, minute, or second values that are less than 10. '1979-10-30 1:2:3' is the same as '1979-10-30 01:02:03'.

Upvotes: 2

hudolejev
hudolejev

Reputation: 6018

AFAIR 19/6/2010 4:56:17 AM is not a valid date format for MySQL date types. You should convert it to 2010-06-19 04:56:14 (see doc).

Upvotes: 1

DrColossos
DrColossos

Reputation: 12988

Have a look at MySQL date functions. They are very extensive and allow a high flexibility.

Besides all that, I would recommend re-thinking your table structure. A timestap as a primary key is not exactly what you want. When you have high traffic, it CAN happen, that the timestamp is the same. Also if you are saving 2 or more records in a row, the timestamp will be the same. Furthermore, your MD5 column is set to int(11). MD5 hashes use mixed characters, so i would rather go with 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`)
) ;

Upvotes: 2

Related Questions