MYSQL Усеченное неверное значение DOUBLE


155

Когда ниже приведен SQL-запрос:

UPDATE shop_category 
SET name = 'Secolul XVI - XVIII' 
    AND name_eng = '16th to 18th centuries' 
WHERE category_id = 4768

Возникает следующая ошибка:

1292 - Truncated incorrect DOUBLE value: 'Secolul XVI - XVIII'

Как это исправить?


shop_category структура таблицы:

category_id   mediumint(8)
name        varchar(250)
name_eng      varchar(250)

1
Можно ли каким-либо образом определить реальный смысл этого сообщения об ошибке и в каких случаях оно появляется? Поскольку это происходит в тех случаях, когда значение DOUBLE не задействовано, оно выглядит несколько вводящим в заблуждение.
— Сик

Угадайте, что он пытается вычислить БУЛЕВОЕ значение 'Secolul XVI - XVIII' до AND.
— Антон Коляев

1
Если у вас есть «где x = 'x' и y», вы получите эту плохо продуманную и неясную ошибку
— Йохан Сноугуз

Ответы:


214

Вам не нужно ANDключевое слово. Вот правильный синтаксис оператора UPDATE :

UPDATE 
    shop_category 
SET 
    name = 'Secolul XVI - XVIII', 
    name_eng = '16th to 18th centuries' 
WHERE 
    category_id = 4768

12
Очень рад, что нашел этот ответ, прежде чем
— вбить

19
так определенно глупо, что люди, подобные мне, совершают эту ошибку, однако «Усеченное неверное значение DOUBLE» является довольно бесполезным предупреждением ...
— rbennell

6
Обычно, когда возникает какая-либо проблема с синтаксисом, он выдает это бесполезное исключение «mysql-truncated-
— invalid

Да ... у меня тоже был похожий опыт при попытке использовать строковый литерал в предложении "где" без кавычек.
— Пранай

Я собирался покончить с собой из-за этого. Слава богу, ты спас мне жизнь. Это глупое И в обновлении. Gau
— Гауравмехла

72

Я получал это исключение не из-за AND вместо запятой, фактически у меня было это исключение только потому, что я не использовал апострофы в предложении where.

Как мой запрос был

update table set coulmn1='something' where column2 in (00012121);

когда я изменил условие where на where column2 in ('00012121');тогда, запрос работал нормально для меня.


2
Та же проблема для меня! Я пытался обновить таблицу в crm, которая использует 1 в качестве идентификатора пользователя с правами администратора и 36 направляющих символов для всех остальных пользователей. Мое где указывал user_id как 1, без кавычек. Я думаю, что это связано с тем, что MySQL находится в строгом режиме.
— dmulvi

3
@danny_mulvihill Я верю, что вы на правильном пути. Я STRICT_TRANS_TABLESустановил sql_modeи попытался обновить поле, ограниченное (как представляется,) числовым значением в whereпредложении, которое вызвало ошибку. Меняя режимы, он вместо этого выдавал предупреждение, но все равно не применил обновление. При ближайшем рассмотрении столбец, использованный в предложении where, несмотря на то, что он имел только то, что казалось целочисленными значениями, на самом деле представлял собойvarchar(20)
— Robert Gannon

Та же проблема для меня. 'Select * from t, где id = 6503' работало нормально, но 'update t set a = "foo", где id = 6503' привело к ошибке 1292 (22007): усечено неверное значение DOUBLE: '234805557438 #'. id выглядит как целое число, но был varchar. Цитирование значения в обновлении решило проблему. 'update t set a = "foo", где id = "6503"'
— gaoithe

Та же проблема для меня при передаче INSERT, который работал в консоли MySQL, но не работал в программном обеспечении интеграции данных Pentaho. Изменили «имя> 1000 и имя <6000» на «имя>« 1000 »и имя <« 6000 »» и работали как шарм.
— Пила

13

Попробуйте заменить ANDс,

UPDATE shop_category 
SET name = 'Secolul XVI - XVIII', name_eng = '16th to 18th centuries' 
WHERE category_id = 4768

UPDATE Синтаксис показывает запятую следует использовать в качестве разделителя.


1
Работал у меня +1 за это :)
— Фейсал

12

Что это в основном

Это неправильный синтаксис, который заставляет MySQL думать, что вы пытаетесь что-то сделать со столбцом или параметром, который имеет неправильный тип «DOUBLE».

Учись на моей ошибке

В моем случае я обновил столбец varchar в таблице, в NULLкоторой 0стояло значение . Мой запрос на обновление был таким:

UPDATE myTable SET myValue = NULL WHERE myValue = 0;

Теперь, так как фактический тип myValueявляется VARCHAR(255)это дает предупреждение:

+---------+------+-----------------------------------------------+
| Level   | Code | Message                                       |
+---------+------+-----------------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'value xyz' |
+---------+------+-----------------------------------------------+

А сейчас myTableпрактически пусто, потому что myValueтеперь NULLна КАЖДОЙ СТРОКЕ в таблице! Как это произошло?
* внутренний крик *

Более 30 тысяч строк теперь имеют недостающие данные.
* внутренний крик усиливается *

Слава Богу за резервные копии. Я был в состоянии восстановить все данные.
* внутренняя интенсивность крика снижается *

Исправленный запрос выглядит следующим образом:

UPDATE myTable SET myValue = NULL WHERE myValue = '0';
                                                  ^^^
                                                  Quotation here!

Хотелось бы, чтобы это было больше, чем просто предупреждение, поэтому забыть эти цитаты менее опасно.

* Конец внутреннего крика *


1
Вы можете установить опцию потерпеть неудачу на предупреждения - см stackoverflow.com/a/4289242/1488762
— Роджер Дик

5

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

SQL Error (1292): Truncated incorrect DOUBLE value: 'N0003'

Тестовые данные

CREATE TABLE `table1 ` (
    `value1` VARCHAR(50) NOT NULL 
);
INSERT INTO table1 (value1) VALUES ('N0003');

CREATE TABLE `table2 ` (
    `value2` VARCHAR(50) NOT NULL 
);

INSERT INTO table2 (value2)
SELECT value1
FROM table1
WHERE 1
ORDER BY value1+0

Проблема в том, ORDER BY value1+0- литье типов.

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


4

В основном это неверные строки запроса.

Неправильно из-за тонкой синтаксической ошибки (неправильно поставленные круглые скобки) при использовании INSTRфункции:

INSERT INTO users (user_name) SELECT name FROM site_users WHERE
INSTR(status, 'active'>0);

Верный:

INSERT INTO users (user_name) SELECT name FROM site_users WHERE
INSTR(status, 'active')>0;

2

Кажется, mysql изящно обрабатывает приведение типов с помощью операторов SELECT. Поле shop_id имеет тип varchar, но операторы select работают

select * from shops where shop_id = 26244317283;

Но когда вы пытаетесь обновить поля

update stores set store_url = 'https://test-url.com' where shop_id = 26244317283;

Сбой с ошибкой. Усеченное неверное значение DOUBLE: '1t5hxq9'

Вам нужно поместить shop_id 26244317283 в кавычки '26244317283', чтобы запрос работал, так как поле имеет тип varchar, а не int

update stores set store_url = 'https://test-url.com' where shop_id = '26244317283';

0

Если вы столкнулись с этой проблемой при использовании вставки, похожей на приведенную ниже, проблема может заключаться просто в отсутствии пробела между --текстом комментария:

insert into myTable (a, b, c)
values (
   123 --something
  ,345 --something else
  ,567 --something something else
);

Проблема в том, что на --somethingсамом деле должно быть -- somethingс пробелом.


0

Я столкнулся с этой ошибкой при использовании bindParam и указании PDO :: PARAM_INT, где я фактически передавал строку. Изменение в PDO :: PARAM_STR исправило ошибку.


0

Я действительно сталкивался с этой ошибкой, когда пытался выполнить WHERE EXIST, где подзапрос соответствовал 2 столбцам, которые случайно были разных типов. В двух таблицах также были разные механизмы хранения.

Один столбец был CHAR (90), а другой - BIGINT (20).

Один стол был InnoDB, а другой - ПАМЯТЬ.

Часть запроса:

[...] AND EXISTS (select objectid from temp_objectids where temp_objectids.objectid = items_raw.objectid );

Изменение типа столбца в одном столбце с BIGINT на CHAR решило проблему.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.