Неправильне значення дати MySQL: '0000-00-00 00:00:00'

Нещодавно я перейняв старий проект, який був створений 10 років тому. Він використовує MySQL 5.1.

Крім усього іншого, мені потрібно змінити набір символів за замовчуванням з latin1 на utf8.

Як приклад, у мене є такі таблиці, як ця:

  CREATE TABLE `users` (
    `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    `first_name` varchar(45) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `last_name` varchar(45) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `username` varchar(127) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `email` varchar(127) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `pass` varchar(20) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL,
    `active` char(1) CHARACTER SET latin1 COLLATE latin1_general_ci NOT NULL DEFAULT 'Y',
    `created` datetime NOT NULL,
    `last_login` datetime DEFAULT NULL,
    `author` varchar(1) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT 'N',
    `locked_at` datetime DEFAULT NULL,
    `created_at` datetime DEFAULT NULL,
    `updated_at` datetime DEFAULT NULL,
    `ripple_token` varchar(36) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    `ripple_token_expires` datetime DEFAULT '2014-10-31 08:03:55',
    `authentication_token` varchar(255) CHARACTER SET latin1 COLLATE latin1_general_ci DEFAULT NULL,
    PRIMARY KEY (`id`),
    UNIQUE KEY `index_users_on_reset_password_token` (`reset_password_token`),
    UNIQUE KEY `index_users_on_confirmation_token` (`confirmation_token`),
    UNIQUE KEY `index_users_on_unlock_token` (`unlock_token`),
    KEY `users_active` (`active`),
    KEY `users_username` (`username`),
    KEY `index_users_on_email` (`email`)
  ) ENGINE=InnoDB AUTO_INCREMENT=1677 DEFAULT CHARSET=utf8 CHECKSUM=1 DELAY_KEY_WRITE=1 ROW_FORMAT=DYNAMIC

Я створив власний Mac для роботи над цим. Не надто замислюючись про це, я запустив "варити встановити mysql", який встановив MySQL 5.7. Тож у мене є деякі конфліктні версії.

Я завантажив копію цієї бази даних та імпортував її.

Якщо я спробую запустити такий запит:

  ALTER TABLE users MODIFY first_name varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci    NOT NULL  

Я отримую цю помилку:

  ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'created' at row 1

Я думав, що можу це виправити за допомогою:

  ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-01 00:00:00';
  Query OK, 0 rows affected (0.06 sec)
  Records: 0  Duplicates: 0  Warnings: 0

але я отримую:

  ALTER TABLE users MODIFY first_name varchar(45) CHARACTER SET utf8 COLLATE utf8_general_ci    NOT NULL ;
  ERROR 1292 (22007): Incorrect datetime value: '0000-00-00 00:00:00' for column 'created' at row 1

Чи потрібно оновлювати кожне значення?

Моя пропозиція, якщо так випливає, що таблиця порожня або не дуже велика - це експортувати оператори створення у форматі .sql, перепишіть їх за своїм бажанням. Також зробіть те саме, якщо у вас є якісь наявні дані, тобто експортувати заяви-вставки (я рекомендую робити це в окремому файлі як створення операторів). Нарешті, опустіть таблицю та виконайте спочатку створення оператора, а потім вставки.

Ви можете використовувати для цього будь-яку mysqldumpкоманду, включену до вашої установки MySQL, або ви також можете встановити MySQL Workbench, який є безкоштовним графічним інструментом, який також включає цей параметр в дуже настроюваний спосіб, не вимагаючи конкретних параметрів команди.

Я не зміг цього зробити:

UPDATE users SET created = NULL WHERE created = '0000-00-00 00:00:00'

(на MySQL 5.7.13).

Я продовжував отримувати Incorrect datetime value: '0000-00-00 00:00:00'помилку.

Як не дивно, це спрацювало: SELECT * FROM users WHERE created = '0000-00-00 00:00:00'. Я поняття не маю, чому перший збій, а останній працює ... можливо помилка MySQL?

У будь-якому випадку цей запит UPDATE працював:

UPDATE users SET created = NULL WHERE CAST(created AS CHAR(20)) = '0000-00-00 00:00:00'

Зміна значень за замовчуванням для стовпця із ALTER TABLEзаявою, наприклад

 ALTER TABLE users MODIFY created datetime  NULL DEFAULT '1970-01-02'

... не змінює жодних значень, які вже зберігаються. Значення "за замовчуванням" застосовується до вставлених рядків і для яких значення не подається для стовпця.

Щодо того, чому ви зіткнулися з помилкою, можливо, sql_modeналаштування вашого сеансу включає NO_ZERO_DATE.

Довідка: http://dev.mysql.com/doc/refman/5.7/uk/sql-mode.html#sqlmode_no_zero_date

Коли ви зробили "імпорт", оператори SQL, які зробили INSERT в цю таблицю, запускалися в сеанс, який дозволив нульові дати.

Щоб переглянути налаштування sql_mode:

SHOW VARIABLES LIKE 'sql_mode' ;

або

SELECT @@sql_mode ;

Що стосується того, як "виправити" поточну проблему, щоб помилка не викидалася під час запуску ALTER TABLEоператора.

Кілька варіантів:

1) змінити sql_modeдозволити нульові дати, видаливши NO_ZERO_DATEі NO_ZERO_IN_DATE. Зміна може бути застосована у файлі my.cnf, тому після перезавантаження MySQL Server sql_modeзмінна буде ініціалізована до налаштування в my.cnf.

Для тимчасової зміни ми можемо змінити налаштування одним сеансом, не вимагаючи глобальної зміни.

-- save current setting of sql_mode
SET @old_sql_mode := @@sql_mode ;

-- derive a new value by removing NO_ZERO_DATE and NO_ZERO_IN_DATE
SET @new_sql_mode := @old_sql_mode ;
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_DATE,'  ,','));
SET @new_sql_mode := TRIM(BOTH ',' FROM REPLACE(CONCAT(',',@new_sql_mode,','),',NO_ZERO_IN_DATE,',','));
SET @@sql_mode := @new_sql_mode ;

-- perform the operation that errors due to "zero dates"

-- when we are done with required operations, we can revert back
-- to the original sql_mode setting, from the value we saved
SET @@sql_mode := @old_sql_mode ;

2) змінити created стовпчик, щоб дозволити значення NULL, і оновити існуючі рядки, щоб змінити нульові дати на нульові значення

3) оновити існуючі рядки, щоб змінити нульові дати на дійсну дату

Для оновлення кожного рядка нам не потрібно запускати окремі заяви. Ми можемо оновити всі рядки одним махом (якщо припустити, що це таблиця з досить великим розміром. Для більшої таблиці, щоб уникнути генерації відколів / відміни, ми можемо виконувати операцію в шматки досить розумного розміру.)

У питанні AUTO_INCREMENTзначення, показане для визначення таблиці, запевняє нас, що кількість рядків не є надмірною.

Якщо ми вже змінили createdстовпець, щоб визначити NULLзначення, ми можемо зробити щось подібне:

UPDATE  `users` SET `created` = NULL WHERE `created` = '0000-00-00 00:00:00'

Або ми можемо встановити їх на дійсну дату, наприклад, 2 січня 1970 року

UPDATE  `users` SET `created` = '1970-01-02' WHERE `created` = '0000-00-00 00:00:00'

(Зверніть увагу, що значення часу в півночі 1 січня 1970 року '1970-01-01 00:00:00') є "нульовою датою". Це буде оцінено як'0000-00-00 00:00:00'

Я вирішив це, зробивши це перед запитом

SET SQL_MODE='ALLOW_INVALID_DATES';

Відповідно до посібника MySQL 5.7 :

Режим SQL за замовчуванням у MySQL 5.7 включає такі режими: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER і NOUS.

Оскільки 0000-00-00 00:00:00це неправдиве DATETIMEзначення, ваша база даних порушена. Ось чому MySQL 5.7 - який входить у NO_ZERO_DATEрежим, включений за замовчуванням - видає помилку при спробі виконати операцію запису.

Ви можете виправити таблицю, оновивши всі недійсні значення до будь-яких інших дійсних, наприклад NULL:

UPDATE users SET created = NULL WHERE created < '0000-01-01 00:00:00'

Також, щоб уникнути цієї проблеми, я рекомендую вам завжди встановлювати поточний час як значення за замовчуванням для ваших createdполів-подібних, тому вони автоматично заповнюються INSERT. Просто зробіть:

ALTER TABLE users
ALTER created SET DEFAULT CURRENT_TIMESTAMP

SET sql_mode = 'NO_ZERO_DATE';
UPDATE `news` SET `d_stop`='2038-01-01 00:00:00' WHERE `d_stop`='0000-00-00 00:00:00'

Ось яке моє рішення PhpMyAdmin / Fedora 29 / MySQL 8.0 (наприклад):

set sql_mode='SOMETHING'; не працює , командний виклик вдалий, але нічого не змінилося.

set GLOBAL sql_mode='SOMETHING'; змінити глобальну конфігурацію постійної зміни.

set SESSION sql_mode='SOMETHING'; зміна конфігурації сеансу Змінна SESSION впливає лише на поточного клієнта.

https://dev.mysql.com/doc/refman/8.0/en/sql-mode.html

Тому я роблю це:

• Отримайте SQL_MODE: SHOW VARIABLES LIKE 'sql_mode';
• Результат: ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION
• Видалити в результаті: NO_ZERO_IN_DATE,NO_ZERO_DATE
• Встановити нову конфігурацію: set GLOBAL SQL_MODE='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION'

Ви можете видалити або додати інший режим таким же чином.

Це корисно для зміни глобального для використання та тестування фреймворків або sql_mode повинні бути вказані у кожному файлі чи купі запитів.

Адаптований із запитання запитайте тут: як-можна-i-відключити-mysql-строгий режим

Приклад: встановити останній вміст Joomla 4.0-альфа.

Редагувати: У PhpMyadmin, якщо ви контролюєте сервер, ви можете змінити sql_mode(та всі інші параметри) безпосередньо вPlus > Variables > sql_mode

Ви можете змінити тип створеного поля від datetimeдо varchar(255), то ви можете встановити (оновити) все записи , які мають значення "0000-00-00 00:00:00"для NULL.

Тепер ви можете робити запити без помилок. Після завершення ви можете змінити тип поля, створеного для datetime.

У мене є ця помилка і після оновлення MySQL з 5.6 до 5.7

Я зрозумів, що найкращим рішенням для мене є поєднання деяких тут рішень і зробити щось із цього, що працюватиме з мінімальним вкладом.

Я використовую MyPHPAdmin для простоти надсилання запитів через інтерфейс, оскільки тоді я можу легко перевірити структуру та все це. Ви можете використовувати ssh безпосередньо чи інший інтерфейс. Метод у будь-якому випадку повинен бути подібним чи однаковим.

...

1.

Спочатку перевірте фактичну помилку при спробі відновити db:

joomla.jos_menu Примітка: стовпці TIME / TIMESTAMP / DATETIME старого формату були оновлені до нового формату.

Попередження: Неправильне значення дати: "0000-00-00 00:00:00" для стовпця "check_out_time" у рядку 1

Помилка: недійсне значення за замовчуванням для "check_out_time"

статус: Операція не вдалася

Це говорить мені, що у стовпці check_out_time в таблиці jos_menu потрібно, щоб усі погані дати були виправлені, а також "змінено за замовчуванням".

...

2.

Я запускаю запит SQL на основі інформації в повідомленні про помилку:

UPDATE jos_menu SET checked_out_time = '1970-01-01 08:00:00' WHERE checked_out_time = 0

Якщо ви отримаєте помилку, ви можете скористатись наведеним нижче запитом, який, здається, завжди працює:

UPDATE jos_menu SET checked_out_time = '1970-01-01 08:00:00' WHERE CAST(checked_out_time AS CHAR(20)) = '0000-00-00 00:00:00'

...

3.

Потім, як тільки це буде зроблено, я запускаю другий запит SQL:

ALTER TABLE `jos_menu` CHANGE `checked_out_time` `checked_out_time` DATETIME NULL DEFAULT CURRENT_TIMESTAMP;

Або у випадку, якщо це дата, яка повинна бути NULL

ALTER TABLE `jos_menu` CHANGE `checked_out_time` `checked_out_time` DATETIME NULL DEFAULT NULL;

...

Якщо я запускаю базу даних ремонту, я отримую:

joomla.jos_menu Добре

...

Працює просто чудово :)

Перевірка

SELECT @@sql_mode;

якщо ви бачите там "ZERO_DATE", спробуйте

SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_ZERO_DATE',''));   
SET GLOBAL sql_mode=(SELECT REPLACE(@@sql_mode,'NO_ZERO_IN_DATE',''));   

Вийдіть і знову ввійдіть до свого клієнта (це дивно) та повторіть спробу

Зробіть режим sql не суворим

якщо за допомогою laravel перейдіть до конфігурації> бази даних, перейдіть до налаштувань mysql і зробіть суворий режим помилковим

У мене була аналогічна проблема, але в моєму випадку для деяких рядків було значення NULL.

тому спочатку я оновлюю таблицю:

update `my_table`set modified = '1000-01-01 00:00:00' WHERE modified is null

Проблема вирішена, принаймні в моєму випадку.

Я також отримав

SQLSTATE [22007]: Недійсний формат часу дати: 1292 Неправильне значення дати: "0000-00-00 00:00:00" для стовпця

інформація про помилку

Виправте це, змінивши 0000-00-00 00:00:00 на 1970-01-01 08:00:00

1970-01-01 08:00:00 часова марка unix дорівнює 0

Я знайшов рішення на https://support.plesk.com/hc/en-us/articles/115000666509-How-to-change-the-SQL-mode-in-MySQL . У мене було таке:

mysql> show variables like 'sql_mode';
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                                                     |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+-------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

Зверніть увагу на NO_ZERO_IN_DATE,NO_ZERO_DATEрезультати вище. Я видалив це, зробивши це:

mysql> SET sql_mode = 'ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';
Query OK, 0 rows affected, 1 warning (0.00 sec)

Тоді у мене було таке:

mysql> show variables like 'sql_mode';
+---------------+--------------------------------------------------------------------------------------------------------------+
| Variable_name | Value                                                                                                        |
+---------------+--------------------------------------------------------------------------------------------------------------+
| sql_mode      | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+---------------+--------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.01 sec)

Після цього я міг ALTER TABLEуспішно використовувати та змінювати свої таблиці.

Це я зробив для вирішення своєї проблеми. Я перевірив локальну MySQL 5.7 ubuntu 18.04.

set global sql_mode="NO_ENGINE_SUBSTITUTION";

Перед тим, як запустити цей запит у глобальному масштабі, я додав файл cnf у каталог /etc/mysql/conf.d . Назва файлу cnf - mysql.cnf та коди

[mysqld]
sql_mode=STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Потім я перезавантажую mysql

sudo service mysql restart

Сподіваюся, це може комусь допомогти.

Це неймовірно некрасиво, але це також швидко вирішило проблему для мене. Вашій таблиці потрібен унікальний ключ, який ви будете використовувати для виправлення стовпчиків. У цьому прикладі первинний ключ називається "id", а розбитий стовпчик часових позначок називається "BadColumn".

1. Виберіть ідентифікатори заплямованих стовпців.

   select id from table where BadColumn='0000-00-00 00:00:00'

2. Зберіть ідентифікатори в рядок з комою. Приклад: 1, 22, 33. Для цього я використовував зовнішню обгортку (сценарій Perl), щоб швидко їх виплюнути.

3. Використовуйте свій список ідентифікаторів для оновлення старих стовпців з дійсною датою (з 1971 по 2038 рік).

   update table set BadColumn='2000-01-01 00:00:00' where id in (1, 22, 33)

Моє рішення

SET sql_mode='';
UPDATE tnx_k2_items
SET created_by = 790
, modified = '0000-00-00 00:00:00'
, modified_by = 0

Замість

UPDATE your_table SET your_column = new_valid_value where your_column = '0000-00-00 00:00:00';

Використовуйте

UPDATE your_table SET your_column = new_valid_value where your_column = 0;

Якщо ви вводите дані вручну, ви можете розглянути питання про видалення значень і нулів на TIMESTAMP (6) .000000, щоб вони стали TIMESTAMP. Це добре працювало зі мною.