MYSQL Valeur DOUBLE incorrecte tronquée


155

Lorsque la requête SQL ci-dessous est exécutée:

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

L'erreur suivante est générée:

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

Comment régler ceci?


shop_category structure de la table:

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

1
La signification réelle de ce message d'erreur peut-elle être déterminée de quelque manière que ce soit, et dans quels cas il apparaît? Comme cela se produit dans des contextes où une valeur DOUBLE n'est pas impliquée, cela semble quelque peu trompeur.
syck

Je suppose qu'il essaie de calculer la valeur BOOLEAN de 'Secolul XVI - XVIII' avant ET.
Anton Kolyaev

1
Si vous avez "où x = 'x' et y", vous obtiendrez cette erreur mal conçue et obscure
Johan Snowgoose

Réponses:


214

Vous n'avez pas besoin du ANDmot - clé. Voici la syntaxe correcte de l'instruction UPDATE :

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

12
Vraiment heureux d'avoir trouvé cette réponse avant de jeter l'ordinateur dans un mur
rbennell

19
si certainement la stupidité de la part de gens comme moi qui font cette erreur, cependant, `` Valeur DOUBLE incorrecte tronquée '' est un message d'avertissement assez inutile ...
rbennell

6
Fondamentalement, chaque fois qu'il y a un problème de syntaxe, il lève cette exception inutile "mysql-truncated-incorrect-double-value"
heman123

Oui ... j'ai aussi eu une expérience similaire en essayant d'utiliser une chaîne littérale dans la clause 'where' sans les guillemets.
pranay

J'étais sur le point de me suicider à cause de cela. Dieu merci, tu m'as sauvé la vie. Ce stupide ET en mise à jour. 😠🤣
gauravmehla

72

J'obtenais cette exception non pas à cause de ET au lieu de la virgule, en fait j'avais cette exception simplement parce que je n'utilisais pas d'apostrophes dans la clause where.

Comme ma requête était

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

quand j'ai changé la clause where en where column2 in ('00012121');alors la requête a bien fonctionné pour moi.


2
Même problème pour moi! J'essayais de mettre à jour une table dans un CRM qui utilise 1 comme identifiant utilisateur de l'utilisateur admin et 36 char guides pour tous les autres utilisateurs. Mon où spécifiait user_id comme 1, sans les guillemets. Je pense que cela est lié au fait que mysql est en mode strict.
dmulvi

3
@danny_mulvihill Je pense que vous êtes sur la bonne voie. J'avais STRICT_TRANS_TABLESinstallé sql_modeet essayé de mettre à jour un champ limité avec (ce qui semblait être) une valeur numérique dans la whereclause a généré une erreur. Changement de mode, il a lancé un avertissement à la place, mais n'a toujours pas appliqué la mise à jour. En y regardant de plus près, la colonne utilisée dans la clause where, bien qu'elle n'ait que ce qui semblait être des valeurs entières, était en fait unvarchar(20)
Robert Gannon

Même problème pour moi. Un 'select * from t où id = 6503' fonctionnait bien mais 'update t set a = "foo" où id = 6503' a entraîné une ERREUR 1292 (22007): valeur DOUBLE incorrecte tronquée: '234805557438 #'. id ressemble à un entier mais était un varchar. Citant la valeur dans la mise à jour a résolu le problème. 'update t set a = "foo" where id = "6503"'
gaoithe

Même problème pour moi lors du passage d'un INSERT qui fonctionnait dans la console mysql mais ne fonctionnait pas dans le logiciel Pentaho Data Integration. Changé "nom> 1000 et nom <6000" en "nom> '1000' et nom <'6000'" et a fonctionné comme un charme.
Sawd

13

Essayez de remplacer le ANDpar,

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

La syntaxe UPDATE indique que la virgule doit être utilisée comme séparateur.


1
A travaillé pour moi +1 pour ça :)
Faisal

12

Qu'est-ce que c'est fondamentalement

C'est une syntaxe incorrecte qui fait penser à MySQL que vous essayez de faire quelque chose avec une colonne ou un paramètre qui a le type incorrect "DOUBLE".

Apprenez de mon erreur

Dans mon cas, j'ai mis à jour la colonne varchar dans un paramètre de table NULLoù la valeur 0se situait. Ma requête de mise à jour était comme ceci:

UPDATE myTable SET myValue = NULL WHERE myValue = 0;

Maintenant, puisque le type réel de myValueest VARCHAR(255)ceci donne l'avertissement:

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

Et maintenant myTableest pratiquement vide, car myValuec'est maintenant NULLpour CHAQUE RANG du tableau! Comment est-ce arrivé?
* hurlement interne *

Plus de 30 000 lignes ont maintenant des données manquantes.
* les hurlements internes s'intensifient *

Dieu merci pour les sauvegardes. J'ai pu récupérer toutes les données.
* L'intensité des cris internes diminue *

La requête corrigée est la suivante:

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

J'aurais aimé que ce soit plus qu'un simple avertissement, il est donc moins dangereux d'oublier ces citations.

* Fin des cris internes *


1
Vous pouvez définir une option pour échouer sur les avertissements - voir stackoverflow.com/a/4289242/1488762
Roger Dueck

5

Je viens de perdre mon temps là-dessus et je voulais ajouter un cas supplémentaire où cette erreur se présente.

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

Données de test

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

Le problème est ORDER BY value1+0- le casting de type.

Je sais qu'il ne répond pas à la question mais c'est le premier résultat sur Google pour cette erreur et il devrait avoir d'autres exemples où cette erreur se présente.


4

Les chaînes de requête non valides donneront cet avertissement.

Mauvais en raison d'une erreur de syntaxe subtile (parenthèse droite mal placée) lors de l'utilisation de la INSTRfonction:

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

Correct:

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

2

Il semble que mysql gère le type de transtypage avec élégance avec les instructions SELECT. Le champ shop_id est de type varchar mais les instructions select fonctionnent

select * from shops where shop_id = 26244317283;

Mais lorsque vous essayez de mettre à jour les champs

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

Il échoue avec l'erreur Valeur DOUBLE incorrecte tronquée: '1t5hxq9'

Vous devez mettre le shop_id 26244317283 entre guillemets '26244317283' pour que la requête fonctionne car le champ est de type varchar pas int

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

0

Si vous rencontrez ce problème avec un insert qui ressemble à celui ci-dessous, le problème peut simplement être le manque d'espace entre --et le texte du commentaire:

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

Le problème avec ceci est que le --somethingdevrait en fait être -- somethingavec un espace.


0

J'ai rencontré cette erreur lors de l'utilisation de bindParam et de la spécification de PDO :: PARAM_INT où je passais en fait une chaîne. Le passage à PDO :: PARAM_STR a corrigé l'erreur.


0

J'ai rencontré cette erreur lorsque j'ai essayé de faire un WHERE EXIST où la sous-requête correspondait à 2 colonnes qui étaient accidentellement de types différents. Les deux tables étaient également des moteurs de stockage différents.

Une colonne était un CHAR (90) et l'autre était un BIGINT (20).

Une table était InnoDB et l'autre était MEMORY.

Partie de la requête:

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

La modification du type de colonne sur une colonne de BIGINT à CHAR a résolu le problème.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.