Je ne sais pas quelle est cette erreur!
#1292 - Truncated incorrect DOUBLE value:
Je n'ai pas de champ ou de données à double valeur!
J'ai perdu une heure entière à essayer de comprendre cela!
voici ma requête
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
voici mon spectacle créer la table pour la table où les résultats vont dans
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
Ce message signifie que vous essayez de comparer un nombre et une chaîne dans une clause WHERE
ou ON
. Dans votre requête, le seul endroit potentiel où cela pourrait se produire est ON ac.company_code = ta.company_code
; soit assurez-vous qu'ils ont des déclarations similaires, soit utilisez un CAST
explicite pour convertir le nombre en chaîne.
Si vous désactivez le mode strict
, l'erreur devrait se transformer en avertissement.
Je faisais face au même problème. Tentative de comparaison d’une colonne varchar (100) avec la valeur numérique 1. Cela a entraîné une erreur 1292. Fixé en ajoutant des guillemets simples autour de 1 ('1').
Merci pour l'explication ci-dessus
J'ai corrigé cette erreur car il y avait une erreur de syntaxe ou des caractères indésirables dans la requête, mais MySQL n'a pas pu l'attraper. J'utilisais and
entre plusieurs champs lors de la mise à jour, par exemple.
update user
set token='lamblala',
accessverion='dummy' and
key='somekey'
where user = 'myself'
Le problème de la requête ci-dessus peut être résolu en remplaçant and
par une virgule (,
)
TL; DR
Cela peut également être dû à l'application de OR
à une chaîne colonnes/littéraux.
Version complète
J'ai reçu le même message d'erreur pour une simple instruction INSERT
impliquant une vue:
insert into t1 select * from v1
bien que toutes les colonnes source et cible soient de type VARCHAR
. Après un certain débogage, j'ai trouvé la cause première; la vue contenait ce fragment:
string_col1 OR '_' OR string_col2 OR '_' OR string_col3
qui était probablement le résultat d'une conversion automatique de l'extrait suivant d'Oracle:
string_col1 || '_' || string_col2 || '_' || string_col3
(||
est une concaténation de chaînes sous Oracle). La solution était d'utiliser
concat(string_col1, '_', string_col2, '_', string_col3)
au lieu.
Quand j’ai reçu cette erreur, j’ai pensé que c’était un bogue, mais vous devez garder à l’esprit que si vous faites une requête séparée avec une instruction SELECT et la même clause WHERE, vous pouvez récupérer l’ID principal de cette instruction SELECT: SELECT CONCAT(primary_id, ',')
) et insérez-les dans la requête UPDATE ayant échoué avec les conditions -> "WHERE [id_primaire] IN ([liste des ID principaux séparés par des virgules à partir de l'instruction SELECT)", ce qui vous permet de résoudre les problèmes causés par la clause WHERE de la requête d'origine .
Pour moi, personnellement, lorsque j'utilisais des guillemets pour les valeurs de "WHERE ____ IN ([values here])", seules 10 des 300 entrées attendues étaient affectées, ce qui, à mon avis, semble être un bug.
Dans mon cas, c’était une insertion de vue (fortement imbriquée, vue en vue) causant l’erreur dans mysql-5.6 :
CREATE TABLE tablename AS
SELECT * FROM highly_nested_viewname
;
La solution de rechange que nous avons finalement utilisée consistait à simuler une vue matérialisée (qui est en réalité un tableau) et à l'insérer/la mettre à jour périodiquement à l'aide de procédures stockées.