Недопустимое значение по умолчанию для поля timestamp 'create_date'
У меня есть следующий оператор создания sql
mysql> CREATE TABLE IF NOT EXISTS `erp`.`je_menus` (
-> `id` INT(11) NOT NULL AUTO_INCREMENT ,
-> `name` VARCHAR(100) NOT NULL ,
-> `description` VARCHAR(255) NOT NULL ,
-> `live_start_date` DATETIME NULL DEFAULT NULL ,
-> `live_end_date` DATETIME NULL DEFAULT NULL ,
-> `notes` VARCHAR(255) NULL ,
-> `create_date` TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
-> `created_by` INT(11) NOT NULL ,
-> `update_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ,
-> `updated_by` INT(11) NOT NULL ,
-> `status` VARCHAR(45) NOT NULL ,
-> PRIMARY KEY (`id`) )
-> ENGINE = InnoDB;
дает следующую ошибку
ERROR 1067 (42000): Invalid default value for 'create_date'
Какая здесь ошибка?
Ответы
Ответ 1
Это из-за SQL-режима сервера - NO_ZERO_DATE.
Из справки: NO_ZERO_DATE
- В строгом режиме не разрешайте '0000-00-00'
как действительную дату. Вы можете вставить нулевые даты с опцией IGNORE. Если не в строгом режиме, дата принимается, но генерируется предупреждение.
Ответ 2
Если вы сгенерировали скрипт из рабочей среды MySQL.
Следующая строка генерируется
SET @[email protected]@SQL_MODE, SQL_MODE='TRADITIONAL,ALLOW_INVALID_DATES';
Удалите TRADITIONAL из SQL_MODE, и тогда скрипт должен нормально работать
Иначе, вы можете установить SQL_MODE как Разрешить недопустимые даты
SET SQL_MODE='ALLOW_INVALID_DATES';
Ответ 3
TIMESTAMP имеет диапазон '1970-01-01 00:00:01' UTC to '2038-01-19 03:14:07' UTC (см. doc). Значение по умолчанию должно быть в этом диапазоне.
Другие нечетные, связанные, поведение:
CREATE TABLE tbl1 (
ts TIMESTAMP);
Query OK, 0 rows affected (0.01 sec)
CREATE TABLE tbl2 (
ts TIMESTAMP,
ts2 TIMESTAMP);
ERROR 1067 (42000): Invalid default value for 'ts2'
CREATE TABLE tbl3 (
ts TIMESTAMP,
ts2 TIMESTAMP DEFAULT '1970-01-01 00:00:01');
Query OK, 0 rows affected (0.01 sec)
Обратите внимание, если вы хотите вставить NULLS:
CREATE TABLE tbl4 (
ts TIMESTAMP NULL DEFAULT NULL);
Ответ 4
В Ubuntu Desktop 16.04 я сделал это:
-
Откройте файл: /etc/mysql/mysql.conf.d/mysqld.cnf
в /etc/mysql/mysql.conf.d/mysqld.cnf
редакторе.
-
Ищите: sql_mode
, он будет где-то под [mysqld]
.
-
и установите sql_mode
в следующее:
NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
-
Сохраните и перезапустите службу MySQL, выполнив:
sudo service mysql restart
Ответ 5
Используя OS X, установите mysql из Homebrew, системные переменные, основанные на своих скомпилированных значениях по умолчанию.
Решение состоит в том, чтобы удалить "NO_ZERO_DATE" из системных переменных "sql_mode".
Просто имейте в виду, что область охвата включает.
Если вы хотите повлиять только на свой сеанс, используйте "@@session"
, например:
SET @@session.sql_mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION".
В этом случае это не повлияет на завершение сеанса или на его изменение. Это не влияет на другую сессию.
Если вы хотите повлиять на всех клиентов, используйте "@@global"
, например:
SET @@global.sql_mode ="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION".
В этом случае это влияет только на клиентов, которые подключаются после изменения (не влияют на текущих всех клиентов) и не будут работать после выхода сервера.
Ответ 6
Я смог решить эту проблему в OS X, установив MySQL из Homebrew
brew install mysql
добавив следующее в /usr/local/etc/my.cnf
sql_mode=ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
и перезапуск MySQL
brew tap homebrew/services
brew services restart mysql
Ответ 7
У меня была аналогичная проблема с MySQL 5.7 со следующим кодом:
`update_date` TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP
Я исправил, используя это вместо:
`update_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
Ответ 8
Чтобы избежать этой проблемы, вам нужно удалить NO_ZERO_DATE
из конфигурации режима mysql.
- Перейти к phpmyadmin.
- После загрузки phpmyadmin, нажмите на вкладку "переменные".
- Ищите "sql mode".
- Нажмите на опцию Edit и удалите
NO_ZERO_DATE
(и его запятую) из конфигурации.
Это очень распространенная проблема в локальной среде с wamp или xamp.
Ответ 9
Вам может потребоваться изучить настройку часового пояса в экземпляре MySql:
mysql> show variables like 'time_zone';
+---------------+--------+
| Variable_name | Value |
+---------------+--------+
| time_zone | SYSTEM |
+---------------+--------+
в моем случае я понял, что базовая система установила часовой пояс на BST, а не на UTC, и поэтому в таблице create по умолчанию "1970-01-01 00:00:01" было принудительно возвращено 1 час, что приводит к недопустимому значению метки времени.
Для меня я действительно хотел, чтобы часовой часовой пояс установлен в UTC, и это меня разобрало. Когда я запускал Centos/7, я просто делал
# timedatectl set-timezone UTC
и перезапустили все.
Ответ 10
Чтобы отключить строгий режим SQL
Create disable_strict_mode.cnf file at /etc/mysql/conf.d/
В файле введите следующие две строки:
[mysqld]
sql_mode=IGNORE_SPACE,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Наконец, перезапустите MySQL с помощью этой команды:
sudo service mysql restart
Ответ 11
пожалуйста, перейдите к вашему phpmyadmin
выбрать базу данных
выбрать таблицу
теперь goto таблица структура
вы можете увидеть здесь в столбце по умолчанию current_timestamp
теперь измените dafaults
нажмите на столбец "action" → table-column- > change
в столбце по умолчанию выберите none
я думаю, ваша проблема решена
![введите описание изображения здесь]()
Ответ 12
Вы можете просто изменить это:
'create_date' TIMESTAMP NOT NULL DEFAULT '0000-00-00 00:00:00',
Чтобы что-то вроде этого:
'create_date' TIMESTAMP NOT NULL DEFAULT '2018-04-01 12:00:00',
Ответ 13
Значения по умолчанию должны начинаться с 1000 года.
Например,
ALTER TABLE mytable last_active DATETIME DEFAULT '1000-01-01 00:00:00'
Надеюсь, это кому-нибудь поможет.
Ответ 14
Самое смешное изменение когда-либо, мистер MySQL. Если поле даты пустое и вводить значение, когда это необходимо, это нормально, но нет, у вас должна быть нелепая запись, начиная с> года 1001, но я использовал поле даты поддержки уже 15 лет, которое вводится только тогда, когда пользователь получает билет поддержки и получает 1 месяц. Но теперь я изменяю это поле на VARCHAR. Какая кучка идиотов! И мы, люди, должны с этим работать.
Ответ 15
На одном сервере с версией 5.1.73 мне пришлось использовать '1970-01-02 00:00:01'
, а не '1970-01-02 00:00:01'
С другой стороны, '1970-01-02 00:00:01'
работал нормально!
Оба не имели значения для переменной sql_mode
.