Código de error 1292 - Valor DOBLE incorrecto truncado - Mysql

85

¡No estoy seguro de cuál es este error!

#1292 - Truncated incorrect DOUBLE value: 

¡No tengo campos o datos de doble valor!

¡He perdido una hora entera tratando de resolver esto!

aquí está mi consulta

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

aquí está mi tabla de creación de programas para la tabla en la que van los resultados

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
Miguel
fuente
7
Según este informe de error, el mensaje proviene de comparar una columna de cadena con un entero, porque ambos se convierten doublepara la comparación. ¿Cómo son ac.company_codey ta.company_codedeclarada?
Barmar
Consulte también bugs.mysql.com/bug.php?id=46641 donde un cartel sugirió que este mensaje de error se reformulara como "DONDE no se permiten las comparaciones entre columnas numéricas y no numéricas"
Barmar
¡Ambas columnas son int (11) y no cadenas!
Mike
¿Puedes hacer un sqlfiddle con algunos datos de muestra?
Barmar

Respuestas:

156

Este mensaje significa que está intentando comparar un número y una cadena en una cláusula WHEREo ON. En su consulta, el único lugar potencial donde podría estar ocurriendo es ON ac.company_code = ta.company_code; asegúrese de que tengan declaraciones similares o use un explícito CASTpara convertir el número en una cadena.

Si apaga el strictmodo, el error debería convertirse en una advertencia.

Barmar
fuente
1
Vaya, qué mensaje de error engañoso. Gracias por ayudar. Usted tenía razón. Necesitaba cambiarme DB::table('contacts')->where('attendance', $int) ->update(["attendance" => $string]);aDB::table('contacts')->where('attendance', '' . $int) ->update(["attendance" => $string]);
Ryan
4
Gracias por esto. Para expandir: hay todo tipo de formas en las que esto se puede activar. En mi caso, estaba usando una expresión regular para extraer un número entero de una cadena y comparar esto con un número entero. Extrañamente, cuando acabo de usar la instrucción SELECT, todo estuvo bien: seleccione xxxx de t1 inner join t2 en t1.id = substr (value, Locate (':', tagvalue) +1) Una vez que lo convertí en un INSERT. ..SELECT, se activó el error.
xgretsch
22

Corregí este error porque había un error de sintaxis o algunos caracteres no deseados en la consulta, pero MySQL no pudo detectarlo. Estaba usando andentre varios campos durante la actualización, por ejemplo

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

El problema en la consulta anterior se puede resolver reemplazando andcon coma ( ,)

user1926248
fuente
Gracias, este no es un gran problema, pero a veces un pequeño problema se convierte en un gran problema
Sumit Kumar Gupta
¡¡¡¡Muchas gracias!!!! Esto me sucedió en el contexto de una declaración de actualización
KC Baltz
8

Estaba enfrentando el mismo problema. Intentando comparar una columna varchar (100) con numérica 1. Resultó en el error 1292. Se corrigió agregando comillas simples alrededor de 1 ('1').

Gracias por la explicación anterior.

ForeverLearner
fuente
3

TL; DR

Esto también puede deberse a la aplicación ORa columnas / literales de cadena.

Versión completa

Recibí el mismo mensaje de error para una INSERTdeclaración simple que involucra una vista:

insert into t1 select * from v1

aunque todas las columnas de origen y destino eran de tipo VARCHAR. Después de algunas depuraciones, encontré la causa raíz; la vista contenía este fragmento:

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

que presumiblemente fue el resultado de una conversión automática del siguiente fragmento de Oracle:

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

( ||es la concatenación de cadenas en Oracle). La solución fue usar

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

en lugar.

Frank Schmitt
fuente
¡Gracias! Nuevo en MySQL, estaba concatenando usando la forma permitida de SQL Server, algo así como string1 + string2 + string3. Su sugerencia de la función concat solucionó este error para mí.
Marcy
1

Cuando recibí este error, creo que fue un error, sin embargo, debe tener en cuenta que si realiza una consulta separada con una instrucción SELECT y la misma cláusula WHERE, puede tomar los ID principales de esa instrucción SELECT SELECT CONCAT(primary_id, ','):) e insertar en la consulta UPDATE fallida con condiciones -> "WHERE [primary_id] IN ([lista de ID primarios separados por comas de la sentencia SELECT)" que le permite aliviar cualquier problema causado por la cláusula WHERE de la consulta original (fallida).

Para mí, personalmente, cuando estaba usando comillas para los valores en "DONDE ____ IN ([valores aquí])", solo 10 de las 300 entradas esperadas estaban siendo afectadas, lo que, en mi opinión, parece un error.

Kylan Hurt
fuente
1

He visto un par de casos en los que se produce este error:

1. usar el operador no es igual !=en una wherecláusula con una lista de orvalores múltiples

como:

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

Esto se puede resolver usando

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

2. falta un operador de comparación en una if()función:

select if(col1,col1,col2);

para seleccionar el valor en col1si existe y en caso contrario mostrar el valor en col2... esto arroja el error; se puede resolver usando:

select if(col1!='',col1,col2);
enarmónico
fuente
0

En mi caso, fue una inserción de vista (altamente anidada, vista a la vista) que causó el error en :

CREATE TABLE tablename AS
  SELECT * FROM highly_nested_viewname
;

La solución alternativa que terminamos haciendo fue simular una vista materializada (que en realidad es una tabla) e insertarla / actualizarla periódicamente mediante procedimientos almacenados.

Nae
fuente
0

Tuve este problema con ES6 y TypeORM al intentar pasar .where("order.id IN (:orders)", { orders }), donde ordershabía una cadena de números separados por comas. Cuando me convertí a una plantilla literal, el problema se resolvió.

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

Si ha usado VERIFICAR RESTRICCIÓN en la tabla para la longitud del campo de cadena

por ejemplo: para comprobar la longitud del nombre de usuario> = 8

utilizar:

CHECK (CHAR_LENGTH(username)>=8)

en vez de

CHECK (username>=8)

corrija la restricción de verificación si alguna tiene una comparación de tipo de datos incorrecta

Trabajo de Varadhan
fuente
0

Si no tiene un campo o datos de doble valor, tal vez debería intentar deshabilitar el modo estricto de sql.

Para hacer eso, debe editar el archivo " my.ini " ubicado en la carpeta de instalación de MySQL, buscar la línea "Establecer el modo SQL en estricto" y cambiar la siguiente línea:

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

a esto, eliminando "STRICT_TRANS_TABLES"

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

Después de eso, debe reiniciar el servicio MySQL para habilitar este cambio.

Para verificar el cambio, abra el editor y ejecute esta oración sql:

SHOW VARIABLES LIKE 'sql_mode';

Muy importante : tenga cuidado con el formato de archivo después de guardar. Guárdelo como "UTF8" y no como "TFT8 con BOM" porque el servicio no se reiniciará.

Bagazo
fuente
Es más seguro hacer esto por sesión, o incluso mejor solo en el script específico que está modificando las 'tablas problemáticas': $pdo->query('SET SESSION SQL_MODE = "ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"')y después de su magia de script, vuelva estrictamente de la misma manera:$pdo->query('SET SESSION SQL_MODE = "STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"')
Piemol