MYSQL truncado incorrecto valor DOBLE


155

Cuando se ejecuta la consulta SQL a continuación:

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

Se genera el siguiente error:

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

¿Cómo arreglar esto?


shop_category estructura de la mesa:

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

1
¿De alguna manera es determinable cuál es el significado real de este mensaje de error y en qué casos aparece? Dado que ocurre en contextos donde un valor DOBLE no está involucrado, parece algo engañoso.
syck

Supongo que intenta calcular el valor booleano de 'Secolul XVI - XVIII' antes de AND.
Anton Kolyaev

1
Si tiene "donde x = 'x' e y" obtendrá este error poco concebido y oscuro
Johan Snowgoose

Respuestas:


214

No necesitas la ANDpalabra clave. Aquí está la sintaxis correcta de la instrucción UPDATE :

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

12
Realmente me alegro de haber encontrado esta respuesta antes de tirar la computadora a la pared
rbennell

19
por lo que definitivamente estupidez por parte de la gente como yo que hacen ese error, sin embargo, 'truncado valor DOBLE incorrectos' es un mensaje de advertencia bastante inútil ...
rbennell

66
Básicamente, siempre que hay algún problema de sintaxis, arroja esta excepción inútil "mysql-truncated-incorrecta-doble-valor"
heman123

Sí, yo también tuve una experiencia similar al intentar usar un literal de cadena en la cláusula 'where' sin las comillas.
pranay

Estaba a punto de suicidarme por esto. Gracias a Dios que me salvaste la vida. Este estúpido Y en actualización. 😠🤣
gauravmehla

72

Obtuve esta excepción no por AND en lugar de coma, de hecho, tuve esta excepción solo porque no estaba usando apóstrofes en la cláusula where.

Como si mi consulta fuera

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

cuando cambié la cláusula where a where column2 in ('00012121');entonces la consulta funcionó bien para mí.


2
¡El mismo problema para mí! Intenté actualizar una tabla en un CRM que usa 1 como ID de usuario del usuario administrador y 36 guías de caracteres para todos los demás usuarios. My where estaba especificando user_id como 1, sin las comillas. Creo que esto está relacionado con que mysql está en modo estricto.
dmulvi

3
@danny_mulvihill Creo que estás en el camino correcto. Había STRICT_TRANS_TABLESestablecido sql_modee intentando actualizar un campo limitado con (lo que parecía ser) un valor numérico en la wherecláusula arrojó un error. Al cambiar de modo, lanzó una advertencia, pero aún no aplicó la actualización. Tras una inspección más cercana, la columna utilizada en la cláusula where, a pesar de tener solo lo que parecían ser valores enteros, era en realidad unvarchar(20)
Robert Gannon

El mismo problema para mí. A 'select * from t where id = 6503' funcionó bien pero 'update t set a = "foo" donde id = 6503' resultó en ERROR 1292 (22007): valor DOBLE incorrecto truncado: '234805557438 #'. id parece entero pero era un varchar. Citar el valor en la actualización resolvió el problema. 'actualizar t establecer a = "foo" donde id = "6503"'
gaoithe

El mismo problema para mí al pasar un INSERT que funcionaba en la consola mysql pero no funcionaba en el software Pentaho Data Integration. Cambió "nombre> 1000 y nombre <6000" a "nombre> '1000' y nombre <'6000'" y funcionó a las mil maravillas.
Sawd

13

Intenta reemplazar el ANDcon,

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

La sintaxis de ACTUALIZACIÓN muestra que la coma debe usarse como separador.


1
Trabajó para mí +1 para ello :)
Faisal

12

Lo que básicamente es

Es una sintaxis incorrecta lo que hace que MySQL piense que está intentando hacer algo con una columna o parámetro que tiene el tipo incorrecto "DOUBLE".

Aprende de mi error

En mi caso, actualicé la columna varchar en una configuración de tabla NULLdonde se encontraba el valor 0. Mi consulta de actualización fue así:

UPDATE myTable SET myValue = NULL WHERE myValue = 0;

Ahora, ya que el tipo real de myValuees VARCHAR(255)esto da la advertencia:

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

¡Y ahora myTableestá prácticamente vacío, porque myValueahora está NULLpor CADA FILA en la tabla! ¿Cómo pasó esto?
* gritos internos *

Más de 30k filas ahora tienen datos faltantes.
* los gritos internos se intensifican *

Gracias a Dios por las copias de seguridad. Pude recuperar todos los datos.
* la intensidad interna de los gritos disminuye *

La consulta corregida es la siguiente:

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

Desearía que esto fuera más que una advertencia, por lo que es menos peligroso olvidar esas citas.

* Fin de los gritos internos *


1
Puede configurar una opción para fallar en las advertencias: consulte stackoverflow.com/a/4289242/1488762
Roger Dueck el

5

Acabo de perder mi tiempo en esto y quería agregar un caso adicional donde este error se presenta.

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

Datos de prueba

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

El problema es ORDER BY value1+0 : tipo de fundición.

Sé que no responde la pregunta, pero este es el primer resultado en Google para este error y debería tener otros ejemplos donde este error se presente.


4

Las cadenas de consulta principalmente inválidas darán esta advertencia.

Incorrecto debido a un error de sintaxis sutil (paréntesis derecho mal colocado) al usar la INSTRfunción:

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

Correcto:

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

2

Parece que mysql maneja el tipo de conversión con gracia con las instrucciones SELECT. El campo shop_id es de tipo varchar pero las sentencias select funcionan

select * from shops where shop_id = 26244317283;

Pero cuando intentas actualizar los campos

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

Se produce un error con el error DOBLE incorrecto truncado: '1t5hxq9'

Debe poner el shop_id 26244317283 entre comillas '26244317283' para que la consulta funcione, ya que el campo es de tipo varchar no int

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

0

Si tiene este problema con una inserción que se parece a la siguiente, el problema puede ser simplemente la falta de espacio entre --el texto del comentario y el siguiente:

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

El problema con esto es que en --somethingrealidad debería estar -- somethingcon un espacio.


0

Experimenté este error al usar bindParam, y al especificar PDO :: PARAM_INT donde realmente estaba pasando una cadena. Cambiar a PDO :: PARAM_STR corrigió el error.


0

Experimenté este error cuando intenté hacer un WHERE EXIST donde la subconsulta coincidía con 2 columnas que, de manera accidental, eran de diferentes tipos. Las dos mesas también tenían diferentes motores de almacenamiento.

Una columna era un CHAR (90) y la otra era un BIGINT (20).

Una mesa era InnoDB y la otra era MEMORY.

Parte de la consulta:

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

Cambiar el tipo de columna en una columna de BIGINT a CHAR resolvió el problema.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.