Estoy involucrado en un proyecto de migración de datos. Recibo el siguiente error cuando intento insertar datos de una tabla en otra tabla (SQL Server 2005):
El mensaje 8152, Nivel 16, Estado 13, Línea 1
Cadena o datos binarios se truncarían.
Las columnas de datos de origen coinciden con el tipo de datos y están dentro de las definiciones de longitud de las columnas de la tabla de destino, por lo que no sé qué podría estar causando este error.
sql-server
tsql
sql-server-2005
migration
data-migration
Jim Evans
fuente
fuente
Respuestas:
Tendrá que publicar las definiciones de tabla para las tablas de origen y destino para que podamos determinar dónde está el problema, pero la conclusión es que una de sus columnas en la tabla de origen es más grande que sus columnas de destino . Puede ser que esté cambiando formatos de una manera que no conocía. El modelo de base de datos del que se está mudando también es importante para descubrirlo.
fuente
Como ya han dicho otros, uno de los tipos de datos de sus columnas en la tabla de origen es más grande que sus columnas de destino.
Una solución simple es simplemente apagar la advertencia y permitir que se produzca el truncamiento. Por lo tanto, si recibe este error pero está seguro de que es aceptable que los datos de su antigua base de datos / tabla se trunquen (corten a tamaño), simplemente puede hacer lo siguiente;
Como se indicó anteriormente, recuerde siempre volver a activar las advertencias después. Espero que esto ayude.
fuente
El problema es bastante simple: una o más de las columnas en la consulta de origen contienen datos que exceden la longitud de su columna de destino. Una solución simple sería tomar su consulta de origen y ejecutarla
Max(Len( source col ))
en cada columna. Es decir,Luego compare esas longitudes con las longitudes de tipo de datos en su tabla de destino. Al menos uno, excede la longitud de su columna de destino.
Si está absolutamente seguro de que este no debería ser el caso y no le importa si no es el caso , entonces otra solución es convertir a la fuerza las columnas de consulta de origen a su longitud de destino (lo que truncará cualquier dato que sea demasiado largo):
fuente
SQL Server 2019 finalmente devolverá un mensaje de error más significativo.
Para habilitar un nuevo comportamiento, debe usarlo
DBCC TRACEON(460)
. Nuevo texto de error desys.messages
:Los datos de cadena o binarios se truncarían: reemplazando el infame error 8152
SQL Server 2017 CU12 también es compatible con esta característica.
Mejora: Reemplazo opcional para el mensaje "La cadena o los datos binarios se truncarían" con información extendida en SQL Server 2017
db <> demostración de violín
fuente
Otra razón potencial para esto es si tiene una configuración de valor predeterminada para una columna que excede la longitud de la columna. Parece que alguien gordo toqueteó una columna que tenía una longitud de 5 pero el valor predeterminado excedía la longitud de 5. Esto me volvió loco ya que estaba tratando de entender por qué no funcionaba en ningún inserto, incluso si todo lo que estaba insertando era una sola columna con un entero de 1. Debido a que el valor predeterminado en el esquema de la tabla tenía ese valor predeterminado que violaba, lo estropeó todo, lo que supongo que nos lleva a la lección aprendida, evite tener tablas con valores predeterminados en el esquema. :)
fuente
Para los demás, también verifique su procedimiento almacenado . En mi caso, en mi procedimiento almacenado,
CustomSearch
accidentalmente declaró que no tenía la longitud suficiente para mi columna, por lo que cuando ingresé una gran cantidad de datos recibí ese error, aunque tengo una gran longitud en mi base de datos. Acabo de cambiar la longitud de mi columna en mi búsqueda personalizada, el error desaparece. Esto es solo para el recordatorio. Gracias.fuente
Esto puede ser un error desafiante. Aquí hay algunas notas tomadas de https://connect.microsoft.com/SQLServer/feedback/details/339410/ busque el comentario de AmirCharania.
Ajusté la respuesta dada por AmirCharania para los datos seleccionados en una tabla real, en lugar de una temporal. Primero seleccione su conjunto de datos en una tabla de desarrollo y luego ejecute lo siguiente:
fuente
Aquí hay una respuesta ligeramente diferente. Es posible que todos los nombres y longitudes de las columnas coincidan, pero quizás esté especificando las columnas en el orden incorrecto en su instrucción SELECT. Digamos que tableX y tableY tienen columnas con el mismo nombre, pero en diferente orden
fuente
Encontré este problema hoy, y en mi búsqueda de una respuesta a este mensaje de error informativo mínimo, también encontré este enlace:
https://connect.microsoft.com/SQLServer/feedback/details/339410/please-fix-the-string-or-binary-data-would-be-truncated-message-to-give-the-column-name
Por lo tanto, parece que Microsoft no tiene planes de expandir el mensaje de error en el corto plazo.
Entonces recurrí a otros medios.
Copié los errores para sobresalir:
(1 fila (s) afectada)
(1 fila (s) afectada)
(1 fila (s) afectada) Msg 8152, Nivel 16, Estado 14, Línea 13 La cadena o los datos binarios se truncarían. La instrucción se ha terminado.
(1 fila (s) afectada)
conté el número de filas en Excel, me acerqué al contador de registros que causó el problema ... ajusté mi código de exportación para imprimir el SQL cerca de él ... luego ejecuté las inserciones de 5 a 10 sql alrededor del problema sql y logró identificar el problema uno, ver la cadena que era demasiado larga, aumentar el tamaño de esa columna y luego el archivo de importación grande no funcionó.
Un poco hack y una solución alternativa, pero cuando te fuiste con muy pocas opciones, haces lo que puedes.
fuente
Sí, también me enfrento a este tipo de problema.
Aquí, he cambiado la longitud del archivo OBSERVACIONES de 500 a 1000
fuente
Voy a agregar otra posible causa de este error solo porque nadie lo ha mencionado y podría ayudar a alguna persona futura (ya que el OP ha encontrado su respuesta). Si la tabla en la que está insertando tiene activadores, podría ser que el activador esté generando el error. He visto que esto sucede cuando se cambiaron las definiciones de los campos de la tabla, pero no las de auditoría.
fuente
Sí, "una pinta en una olla de media pinta no irá". No he tenido mucha suerte (por el motivo que sea) con los diversos SP que la gente ha sugerido, PERO siempre y cuando las dos tablas estén en la misma base de datos (o puede incluirlas en la misma base de datos), puede usar INFORMATION_SCHEMA. COLUMNAS para localizar los campos errantes, por lo tanto:
Esto le permitirá desplazarse hacia arriba y hacia abajo, comparando las longitudes de campo a medida que avanza. Las secciones comentadas le permiten ver (una vez sin comentar, obviamente) si hay desajustes de tipos de datos, o muestran específicamente aquellos que difieren en la longitud del campo, porque soy demasiado vago para desplazarse, solo tenga en cuenta que todo se basa en la fuente nombres de columna que coinciden con los del objetivo.
fuente
Estaba usando una cadena vacía '' en la creación de la tabla y luego recibí el error 'Msg 8152, la cadena o los datos binarios se truncarían' en la actualización posterior. Esto sucedía debido a que el valor de actualización contenía 6 caracteres y era más grande que la definición de columna anticipada. Utilicé "ESPACIO" para solucionar esto solo porque sabía que estaría actualizando en masa después de la creación de datos inicial, es decir, la columna no iba a permanecer vacía por mucho tiempo.
TAN GRANDE CUEVA AQUÍ: Esta no es una solución particularmente ingeniosa, pero es útil en el caso de que esté reuniendo un conjunto de datos, por ejemplo, para solicitudes de inteligencia únicas en las que está creando una tabla para la minería de datos, aplicando un procesamiento / interpretación masiva y almacenamiento de resultados antes y después para una comparación / extracción posterior. Este es un hecho frecuente en mi línea de trabajo.
Inicialmente puede completar utilizando la palabra clave ESPACIO, es decir
Las actualizaciones posteriores a "column_name" de 10 caracteres o menos (sustitúyalas según corresponda) se permitirán sin causar un error truncado. Nuevamente, solo usaría esto en escenarios similares a los descritos en mi advertencia.
fuente
He creado un procedimiento almacenado que analiza una tabla o consulta de origen con varias características por columna, entre las que se incluyen la longitud mínima (min_len) y la longitud máxima (max_len).
Guardo este procedimiento en la base de datos maestra para poder usarlo en todas las bases de datos así:
Y la salida es:
column description constraint_type fk_table fk_column pos default null data_type length precision radix is_unique min_len max_len nulls blanks numerics distincts distinct_values remarks
id_individual NULL PRIMARY KEY NULL NULL 1 NULL NO int NULL 10 10 1 1 2 0 0 70 70 Many (70) unique,all numeric,
id_brand NULL NULL NULL NULL 2 NULL NO int NULL 10 10 0 1 1 0 0 70 2 2,3 same length,all numeric, guid NULL NULL NULL NULL 3 (newid()) NO uniqueidentifier NULL NULL NULL 1 36 36 0 0 0 70 Many (70) unique,same length,
customer_id NULL NULL NULL NULL 4 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
email NULL NULL NULL NULL 5 NULL YES varchar 100 NULL NULL 0 4 36 0 0 0 31 Many (31)
mobile NULL NULL NULL NULL 6 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
initials NULL NULL NULL NULL 7 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
title_short NULL NULL NULL NULL 8 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
title_long NULL NULL NULL NULL 9 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
firstname NULL NULL NULL NULL 10 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
lastname NULL NULL NULL NULL 11 NULL YES varchar 50 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
address NULL NULL NULL NULL 12 NULL YES varchar 100 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
pc NULL NULL NULL NULL 13 NULL YES varchar 10 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
kixcode NULL NULL NULL NULL 14 NULL YES varchar 20 NULL NULL 0 NULL NULL 70 0 0 0 NULL all null,empty,
date_created NULL NULL NULL NULL 15 (getdate()) NO datetime NULL NULL NULL 1 19 19 0 0 0 70 Many (70) unique,same length,
created_by NULL NULL NULL NULL 16 (user_name()) NO varchar 50 NULL NULL 0 13 13 0 0 0 1 loyalz-public same length,
id_location_created NULL FOREIGN KEY location id_location 17 NULL YES int NULL 10 10 0 1 1 0 0 70 2 1,2 same length,all numeric, id_individual_type NULL FOREIGN KEY individual_type id_individual_type 18 NULL YES int NULL 10 10 0 NULL NULL 70 0 0 0 NULL all null,empty,
optin NULL NULL NULL NULL 19 NULL YES int NULL 10 10 0 1 1 39 0 31 2 0,1 same length,
fuente
sp_
prefijo para los procedimientos almacenados. Microsoft ha reservado ese prefijo para su propio uso (consulte Procedimientos almacenados de nomenclatura ) , y corre el riesgo de un choque de nombres en algún momento en el futuro. También es malo para el rendimiento de su procedimiento almacenado . Es mejor simplemente evitarsp_
y usar algo más como prefijo, ¡o sin prefijo!Escribí un procedimiento de almacenamiento útil para ayudar a identificar y resolver el problema del truncamiento de texto (la cadena o los datos binarios se truncarían) cuando se usa la instrucción INSERT SELECT. Compara los campos CHAR, VARCHAR, NCHAR Y NVARCHAR únicamente y devuelve un campo de evaluación campo por campo en caso de ser la posible causa del error.
CÓDIGO DE FUNCIÓN:
Por ahora solo admite los tipos de datos CHAR, VARCHAR, NCHAR y NVARCHAR . Puede encontrar la última versión de este código en el siguiente enlace a continuación y nos ayudamos mutuamente a mejorarlo. GetFieldStringTruncate.sql
https://gist.github.com/jotapardo/210e85338f87507742701aa9d41cc51d
fuente
Si está utilizando SQL Server 2016-2017: para solucionarlo, active la marca de seguimiento 460
y asegúrese de apagarlo después de:
fuente
fuente
Esto también puede ocurrir cuando no tienes los permisos adecuados
fuente
Tuve un problema similar Estaba copiando datos de una tabla a una tabla idéntica en todo menos en el nombre.
Eventualmente volqué la tabla fuente en una tabla temporal usando una instrucción SELECT INTO.
Comparé el esquema de la tabla fuente con la tabla temporal. Encontré que una de las columnas era un
varchar(4000)
cuando esperaba unvarchar(250)
.ACTUALIZACIÓN: El problema varchar (4000) se puede explicar aquí en caso de que esté interesado:
Para Nvarchar (Max), ¿solo obtengo 4000 caracteres en TSQL?
Espero que esto ayude.
fuente
Este error se produce cuando la columna de una tabla pone restricciones [principalmente longitud]. . Por ejemplo, si el esquema de la base de datos para la columna myColumn es CHAR (2), cuando llame desde cualquiera de sus aplicaciones para insertar valor, debe pasar una cadena de longitud dos.
El error básicamente lo dice; la cadena de longitud tres y superior es inconsistente para ajustarse a la restricción de longitud especificada por el esquema de la base de datos. Es por eso que SQL Server advierte y arroja la pérdida de datos / error de truncamiento.
fuente
Por favor, intente el siguiente código:
fuente