Усечение данных SQL для значения даты

#sql

#sql

Вопрос:

Мне трудно создать простую таблицу:

 CREATE TABLE `csat` (
    `csat_id` INT NOT NULL AUTO_INCREMENT,
    `value` INT,
    `month` DATE NOT NULL,
    PRIMARY KEY (`csat_id`)
);

CREATE TABLE `migrated` (
    `migrated_id` INT NOT NULL AUTO_INCREMENT,
    `title` INT,
    `description` INT,
    `month` DATE NOT NULL,
    PRIMARY KEY (`migrated_id`)
);

INSERT INTO csat
VALUES (1, 1, 2017-06-15);

INSERT INTO migrated
VALUES (1, 2, 2018-06-15);
  

Я получаю сообщение об ошибке:
Усечение данных: неверное значение даты: ‘1996’ для столбца ‘месяц’ в строке 1

Похоже, что моя дата в правильном формате:https://www.w3schools.com/sql/func_mysql_date.asp

Мне также интересно, почему мне нужно указывать значение в csat_id, потому что я думал, что SQL просто вставит это для меня, поскольку это первичный ключ.

Комментарии:

1. добавьте какой-нибудь правильный пример ошибки ввода-вывода, поскольку я мог видеть, что 1996 год недействителен, но нигде в i / p

2. 1996 происходит потому, что sql интерпретирует это как 2017, вычтите 6, вычтите 15. Джеймс предоставил достаточный ввод.

3. Верно ли, что для каждой базы данных должно быть указано то же значение 1996, что и ошибка? В качестве опции укажите имя базы данных

Ответ №1:

Вы должны заключить свои значения даты в одинарные кавычки: '2017-06-15' , не 2017-06-15 . Прямо сейчас MySQL оценивает это как 2017 minus 6 minus 15 , что соответствует 1996 году.

Кроме того, при вставке лучше указать столбцы, в которые вы вставляете. И если для вашего столбца установлено значение AUTO_INCREMENT , вам не нужно указывать его:

ВСТАВИТЬ В csat
(`значение`, `месяц`)
ЗНАЧЕНИЯ 
(1, '2017-06-15');

Я бы также подумал об изменении имен ваших столбцов. Возможно, сделать «значение» более описательным (значение чего?) И month вводит в заблуждение, поскольку на самом деле это столбец типа даты.

Ответ №2:

Вы не указали, какой сервер базы данных вы используете, но, вообще говоря, даты вводятся в виде строк.

Вы должны попробовать следующие вставки;

 INSERT INTO csat (`csat_id`, `value`, `month`)
VALUES (1, 1, '2017-06-15');

INSERT INTO migrated (`migrated_id`, `title`, `description`, `month`)
VALUES (1, 2, 2, '2018-06-15');
  

Кроме того, вы должны указать, в какие столбцы вы вставляете. Это предотвращает ввод данных в неправильные поля, особенно при изменении схемы.

SQL автоматически увеличивает поля первичного ключа (если определено таким образом). Однако вам пришлось определить это в ваших инструкциях insert, потому что вы не указали столбцы, в которые вы вставляли.

Попробуйте это вместо;

 INSERT INTO csat (`value`, `month`)
VALUES (1, '2017-06-15');

INSERT INTO migrated (`title`, `description`, `month`)
VALUES (2, 2, '2018-06-15');
  

Комментарии:

1. Хотя я бы использовал одинарные кавычки, а не двойные кавычки. Стандарт SQL является единым, и даже MySQL использует одинарные кавычки на своей справочной странице даты / времени .

2. Да, я согласен с вами. Single является более стандартным.

Ответ №3:

Я предполагаю, что вы пропустили отдельные qoutes (в соответствии со стандартами Sql) сначала в вашей дате, а затем при вставке, даже если столбец является автоинкрементным, вам нужно указать столбцы, отличные от столбца автоинкрементного, чтобы убедиться, что данные, которые вы вставляете, принадлежат этому конкретному столбцу, или не попробовать это

 INSERT INTO 
  csat(value,month) values 
  (1,'2017-06-15')
  

Комментарии:

1. Хотя я бы использовал одинарные кавычки, а не двойные кавычки. Стандарт SQL является единым, и даже MySQL использует одинарные кавычки на своей справочной странице даты / времени .

2. Да, это стандарт для использования одинарных кавычек в sql, а двойные кавычки должны быть такими, чтобы время от времени различаться. Я думаю, что большая часть базы данных допускает использование обоих, хотя

3. На самом деле, большинство других баз данных требуют одинарных кавычек и интерпретируют двойные кавычки по-разному (вы можете протестировать, например, в SQL Server и Postgres).

4. Я использовал oracle, хотя я был специфичен для этого. Я отредактировал свой ответ как qoutes

5. Хотя и Oracle, и MySQL имеют текст, подобный следующему: «Если включен режим ANSI_QUOTES SQL, строковые литералы могут заключаться только в одинарные кавычки, поскольку строка, заключенная в двойные кавычки, интерпретируется как идентификатор». Итак, я бы сказал, что вам все же лучше придерживаться стандарта SQL.