Код ошибки 1292 - усеченное неправильное значение DOUBLE - Mysql

87

Я не уверен, что это за ошибка!

#1292 - Truncated incorrect DOUBLE value: 

У меня нет поля с двойным значением или данных!

Я потратил целый час, пытаясь понять это!

вот мой запрос

INSERT INTO call_managment_system.contact_numbers 
    (account_id, contact_number, contact_extension, main_number, created_by)
SELECT
    ac.account_id,
    REPLACE(REPLACE(REPLACE(REPLACE(ta.phone_number, '-', ''), ' ', ''), ')', ''),'(','') AS Phone,
    IFNULL(ta.ext, '') AS extention,
    '1' AS MainNumber,
    '2' AS created_by
FROM 
    cvsnumbers AS ta
    INNER JOIN accounts AS ac ON ac.company_code = ta.company_code
WHERE 
    LENGTH(REPLACE(REPLACE(REPLACE(REPLACE(ta.phone_number, '-', ''), ' ', ''), ')', ''),'(','') ) = 10

вот моя таблица создания шоу для таблицы, в которую входят результаты

CREATE TABLE `contact_numbers` (  
    `number_id` int(10) unsigned NOT NULL AUTO_INCREMENT,  
    `account_id` int(10) unsigned NOT NULL DEFAULT '0',  
    `person_id` int(11) NOT NULL DEFAULT '0',  
    `contact_number` char(15) NOT NULL,  
    `contact_extension` char(10) NOT NULL DEFAULT '',  
    `contact_type` enum('Primary','Direct','Cell','Fax','Home','Reception','Office','TollFree') NOT NULL DEFAULT 'Primary',  
    `contact_link` enum('Account','PDM','Other') NOT NULL DEFAULT 'Account',  
    `status` tinyint(1) NOT NULL DEFAULT '1' COMMENT '0 = inactive, 1=active', 
    `main_number` tinyint(1) NOT NULL DEFAULT '0' COMMENT '1 = main phone number',  
    `created_on` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,  
    `created_by` int(11) NOT NULL,  
    `modified_on` datetime DEFAULT NULL,  
    `modified_by` int(11) NOT NULL DEFAULT '0',  
    PRIMARY KEY (`number_id`),  
    KEY `account_id` (`account_id`),  
    KEY `person_id` (`person_id`)
) ENGINE=InnoDB AUTO_INCREMENT=534 DEFAULT CHARSET=utf8
Майк
источник
8
Согласно этому отчету об ошибке, сообщение возникает при сравнении строкового столбца с целым числом, потому что они оба преобразуются в doubleдля сравнения. Как так ac.company_codeи ta.company_codeзаявлены?
Barmar
См. Также bugs.mysql.com/bug.php?id=46641, где автор предлагал изменить формулировку этого сообщения об ошибке на «ГДЕ сравнения числовых и нечисловых столбцов не разрешены»
Бармар
Оба эти столбца - это int (11), а не строки!
Майк
Можете ли вы создать sqlfiddle с некоторыми образцами данных?
Barmar

Ответы:

159

Это сообщение означает, что вы пытаетесь сравнить число и строку в предложении WHEREили ON. В вашем запросе единственное возможное место, где это могло произойти, - это ON ac.company_code = ta.company_code; либо убедитесь, что у них есть похожие объявления, либо используйте явное выражение CASTдля преобразования числа в строку.

Если выключить strictрежим, ошибка должна превратиться в предупреждение.

Barmar
источник
1
Вау, какое вводящее в заблуждение сообщение об ошибке. Спасибо за помощь. Ты был прав. Мне нужно было переодеться DB::table('contacts')->where('attendance', $int) ->update(["attendance" => $string]);вDB::table('contacts')->where('attendance', '' . $int) ->update(["attendance" => $string]);
Райан
4
Спасибо за это. Чтобы расширить: есть много способов, которыми это может быть вызвано. В моем случае он использовал регулярное выражение для извлечения целого числа из строки и сравнения его с целым числом. Как ни странно, когда я просто использовал оператор SELECT, все было нормально: выберите xxxx из t1 внутреннего соединения t2 на t1.id = substr (value, locate (':', tagvalue) +1) Как только я превратил это в INSERT. ..SELECT, возникла ошибка.
xgretsch
22

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

update user 
set token='lamblala', 
    accessverion='dummy' and 
    key='somekey' 
where user = 'myself'

Проблема в приведенном выше запросе может быть решена путем замены andзапятой ( ,)

user1926248
источник
Спасибо, это не большая проблема, но иногда небольшая проблема становится большой проблемой
Сумит Кумар Гупта
Огромное спасибо!!!! Это произошло со мной в контексте заявления об обновлении
KC Baltz
8

Я столкнулся с той же проблемой. Попытка сравнить столбец varchar (100) с числовым 1. Приведена ошибка 1292. Исправлено добавлением одинарных кавычек вокруг 1 ('1').

Спасибо за объяснение выше

ForeverLearner
источник
3

TL; DR

Это также может быть вызвано применением ORк строковым столбцам / литералам.

Полная версия

У меня такое же сообщение об ошибке для простого INSERTоператора, связанного с представлением:

insert into t1 select * from v1

хотя все исходные и целевые столбцы были типа VARCHAR. После некоторой отладки я нашел основную причину; представление содержало этот фрагмент:

string_col1 OR '_' OR string_col2 OR '_' OR string_col3

что предположительно было результатом автоматического преобразования следующего фрагмента из Oracle:

string_col1 || '_' || string_col2 || '_' || string_col3

( ||это конкатенация строк в Oracle). Решением было использовать

concat(string_col1, '_', string_col2, '_', string_col3)

вместо.

Франк Шмитт
источник
Спасибо! Новичок в MySQL, я выполнял конкатенацию, используя разрешенный способ SQL Server, что-то вроде string1 + string2 + string3. Ваше предложение функции concat исправило эту ошибку для меня.
Марси
1

Когда я получил эту ошибку, я считаю, что это ошибка, однако вы должны иметь в виду, что если вы выполните отдельный запрос с оператором SELECT и тем же предложением WHERE, вы можете получить первичный идентификатор из этого оператора SELECT SELECT CONCAT(primary_id, ','):) и вставить их в неудачный запрос UPDATE с условиями -> «WHERE [primary_id] IN ([список разделенных запятыми первичных идентификаторов из оператора SELECT)», что позволяет устранить любые проблемы, вызванные предложением WHERE исходного (неудачного) запроса.

Лично для меня, когда я использовал кавычки для значений в «WHERE ____ IN ([значения здесь])», затрагивались только 10 из 300 ожидаемых записей, что, на мой взгляд, кажется ошибкой.

Килан Хёрт
источник
1

Я видел пару случаев, когда возникает эта ошибка:

1. использование оператора не равно !=в whereпредложении со списком из нескольких orзначений

такие как:

where columnName !=('A'||'B')

Это можно решить, используя

where columnName not in ('A','B')

2. отсутствует оператор сравнения в if()функции:

select if(col1,col1,col2);

чтобы выбрать значение в, col1если оно существует, и в противном случае отобразить значение в col2... это вызывает ошибку; это можно решить, используя:

select if(col1!='',col1,col2);
энгармонический
источник
0

В моем случае это была вставка представления (с высокой степенью вложенности, представления в представлении), вызывающая ошибку в :

CREATE TABLE tablename AS
  SELECT * FROM highly_nested_viewname
;

В итоге мы решили имитировать материализованное представление (которое на самом деле представляет собой таблицу) и периодически вставлять / обновлять его с помощью хранимых процедур.

Nae
источник
0

Была эта проблема с ES6 и TypeORM при попытке передать .where("order.id IN (:orders)", { orders }), где ordersбыла строка чисел, разделенных запятыми. Когда я преобразовал в шаблонный литерал, проблема была решена.

.where(`order.id IN (${orders})`);
mdawsondev
источник
0

Если вы использовали CHECK CONSTRAINT в таблице для длины строкового поля

например: чтобы проверить длину имени пользователя> = 8

использование:

CHECK (CHAR_LENGTH(username)>=8)

вместо

CHECK (username>=8)

исправьте ограничение проверки, если у них есть неправильное сравнение типов данных

Работа Варадхана
источник
0

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

Для этого вам нужно отредактировать файл my.ini, расположенный в папке установки MySQL, найти строку «Установить строгий режим SQL» и изменить следующую строку:

# Set the SQL mode to strict
sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

к этому, удалив "STRICT_TRANS_TABLES"

# Set the SQL mode to strict
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

После этого вам необходимо перезапустить службу MySQL, чтобы изменения вступили в силу.

Чтобы проверить изменение, откройте редактор и выполните это предложение sql:

SHOW VARIABLES LIKE 'sql_mode';

Очень важно : будьте осторожны с форматом файла после сохранения. Сохраните его как «UTF8», а не как «TFT8 с спецификацией», потому что служба не будет перезапущена.

Марк
источник
Это более безопасно делать на основе сеанса, или даже лучше только в конкретном сценарии, который изменяет «проблемные таблицы»: $pdo->query('SET SESSION SQL_MODE = "ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"')и после магии сценария вернитесь назад таким же образом:$pdo->query('SET SESSION SQL_MODE = "STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"')
Piemol