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 Синтаксис показывает запятую следует использовать в качестве разделителя.

codaddict
источник
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!

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

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

halfpastfour.am
источник
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 для этой ошибки, и у него должны быть другие примеры, где эта ошибка представляет себя.

hrvoj3e
источник
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 исправило ошибку.

Bytech
источник
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 решило проблему.

thephper
источник