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

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

#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

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

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

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

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

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

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

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

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)

вместо.

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

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

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

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);

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

CREATE TABLE tablename AS
  SELECT * FROM highly_nested_viewname
;

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

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

.where(`order.id IN (${orders})`);

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

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

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

CHECK (CHAR_LENGTH(username)>=8)

вместо

CHECK (username>=8)

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

Если у вас нет поля или данных с двойным значением, возможно, вам стоит попробовать отключить строгий режим 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 с спецификацией», потому что служба не будет перезапущена.