Проблема вставки значения метки времени в MySQL - PullRequest
Новая
       5

Проблема вставки значения метки времени в MySQL

1 голос
/ 19 июня 2010

Есть еще несколько вопросов, когда у людей возникают проблемы с тем, что отметка времени - все нули.Я проверил их, и это не дубликат.

Я объявляю таблицу следующим образом: 

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

У меня также есть вторая таблица, которая будет иметь метку времени в качестве первичного ключа, и они должныимеют то же значение.

При кодировании в Delphi я использую SELECT CURRENT_TIMESTAMP, который возвращает что-то вроде '19/6/2010 4:56:17 AM', которое затем я использую в операторе INSERT.INSERT успешен, но отметка времени - все нули.

Что я делаю не так?

Вот код INSERT: 

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

Вставка будет крайне низкой,одна запись каждые несколько недель или, может быть, месяцев, поэтому я доволен отметкой времени в качестве первичного ключа.Я держу «версии» вещей, поэтому временная метка имеет для меня смысл.

Я умоляю подумать, что это проблема ADO, хотя я ожидаю, что ADO просто «пройдет».Я не вижу другого решения.В консоли вывод «правильный», но при запуске через ADO в Delphi он неправильный

Могу ли я указать MySQL, как он должен форматировать даты?

Ответы [ 3 ]

2 голосов
/ 19 июня 2010

После просмотра документации по MySQL выясняется, что, если ваше значение timestamp неправильно отформатировано, обычно это означает, что отметка времени будет '0000-00-00 00:00:00'.В любом случае вам не нужно указывать значение метки времени - это преимущество TIMESTAMP над DATETIME.И даже если вы это сделали, вы можете просто установить его на NOW() вместо выполнения ненужного SELECT заявления.

Редактировать:

Кроме того, я знаю, что вы сказали, что продумали это,но вы рассматривали летнее время?Это может привести к тому, что две записи будут иметь одну и ту же метку времени, когда часы будут переведены назад осенью.

Редактировать 2:

K, я не знаю, почему я не уловил это раньше,но указанный вами формат отметки времени неверен.Попробуйте ввести правильную метку времени, например '2010/06/19 4:56:17'.MySQL имеет довольно удобный синтаксический анализ значений даты и времени, но это всегда должны быть год-месяц-дата и час-минуты-секунды.

Edit 3:

Хорошо, похоже,Небольшая путаница по этому поводу, поэтому я опубликую эту цитату со страницы документации MySQL 5.0 в формате DATETIME :

Для значений, указанных в виде строк, включающих датуразделители частей, нет необходимости указывать две цифры для значений месяца или дня, которые меньше 10. «1979-6-9» - это то же самое, что и «1979-06-09».Аналогично, для значений, указанных в виде строк, которые включают разделители временной части, нет необходимости указывать две цифры для значений часов, минут или секунд, которые меньше 10. '1979-10-30 1: 2: 3' то же самоекак «1979-10-30 01:02:03».

2 голосов
/ 19 июня 2010

Посмотрите на Функции даты MySQL .Они очень обширны и обеспечивают высокую гибкость.

Кроме того, я бы рекомендовал переосмыслить структуру вашей таблицы.Временная метка в качестве первичного ключа не совсем то, что вы хотите.Когда у вас высокий трафик, МОЖЕТ случиться, что отметка времени совпадает.Также, если вы сохраняете 2 или более записей подряд, отметка времени будет одинаковой.Кроме того, ваш столбец MD5 установлен в int (11).Хеши MD5 используют смешанные символы, поэтому я бы предпочел использовать 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`)
) ;
1 голос
/ 19 июня 2010

AFAIR 19/6/2010 4:56:17 AM не является допустимым форматом даты для типов данных MySQL. Вам следует преобразовать его в 2010-06-19 04:56:14 (см. doc ).

...