ssis - seguridad - restricciones de integridad sql
El valor violó las restricciones de integridad para la columna (6)
¡Elimine filas vacías de Excel después de su última fila de datos!
Algunas veces, las filas vacías en Excel todavía se consideran como datos, por lo tanto, intentar importarlas en una tabla con una o más columnas que no admiten nulos viola las restricciones de la columna.
Solución: seleccione todas las filas vacías en su hoja, incluso aquellas después de su última fila de datos, y haga clic en Eliminar filas.
Obviamente, si algunos de sus datos realmente violan cualquiera de las restricciones de su tabla, simplemente corrija sus datos para que coincidan con las reglas de su base de datos.
Estoy tratando de importar los datos del archivo de Excel a la base de datos de SQL Server. No puedo hacerlo porque estoy recibiendo errores de seguimiento en el archivo de registro. Por favor ayuda. Los errores de registro son los siguientes:
[Destino OLE DB [42]] Error: OLE DB error ha ocurrido. Código de error: 0x80040E21. Un registro OLE DB está disponible. Origen: "Microsoft SQL Native Client" Hresult: 0x80040E21 Descripción: "Operación OLE DB de varios pasos generó errores. Revise cada valor de estado de OLE DB, si está disponible. No se realizó ningún trabajo".
[Destino OLE DB [42]] Error: Hubo un error con la columna de entrada "Copia de F2" (5164) en la entrada "Entrada de destino OLE DB" (55). El estado de columna devuelto fue: "El valor violó las restricciones de integridad para la columna".
[OLE DB Destination [42]] Error: "Entrada" OLE DB Destination Input "(55)" falló porque ocurrió el código de error 0xC020907D y la disposición de fila de error en "entrada" OLE DB Destination Input "(55)" especifica falla en error Se produjo un error en el objeto especificado del componente especificado.
Error [DTS.Pipeline]: El método ProcessInput en el componente "OLE DB Destination" (42) falló con el código de error 0xC0209029. El componente identificado devolvió un error del método ProcessInput. El error es específico del componente, pero el error es fatal y hará que la tarea de flujo de datos deje de ejecutarse.
Error [DTS.Pipeline]: El subproceso "WorkThread0" ha salido con el código de error 0xC0209029.
[Origen de Excel [174]] Error: El intento de agregar una fila al búfer de la tarea de flujo de datos falló con el código de error 0xC0047020.
Error [DTS.Pipeline]: el método PrimeOutput en el componente "Fuente de Excel" (174) arrojó el código de error 0xC02020C4. El componente devolvió un código de falla cuando el motor de la tubería llamó a PrimeOutput (). El significado del código de falla lo define el componente, pero el error es fatal y la tubería dejó de ejecutarse.
Descubrí que esto puede suceder debido a varias razones diferentes.
En mi caso, cuando me desplazo hasta el final de la importación de SQL "Informe", debajo del encabezado "Post-execute (Success)" me dirá cuántas filas se copiaron y generalmente es la siguiente fila en la hoja que tiene el problema. También puede decir qué columna contiene los mensajes de importación (en su caso fue "Copia de F2") para que pueda averiguar cuál fue la celda infractora en Excel.
Lo he visto por razones muy tontas, como que el formato de fecha en Excel sea diferente de las filas anteriores. Por ejemplo, la celda A2 es "05/02/2017", mientras que A3 es "5/2/2017" o incluso "05-02-2017". Parece que lo importante es que las cosas sean perfectamente consistentes.
Incluso si los formatos de Excel son diferentes, entonces si B2 es "512" pero un formato de "Número" de Excel y B3 es "512" pero un formato de "Texto" de Excel, la Celda causará un error.
También he tenido situaciones en las que literalmente tuve que eliminar todas las filas "vacías" debajo de mis filas de datos en la hoja de Excel. A veces aparecen vacíos, pero Excel considera que tienen datos "en blanco" o algo así, por lo que la importación también intenta importarlos. Esto generalmente sucede si ha tenido datos anteriores en su hoja de Excel que ha borrado pero no ha eliminado correctamente las filas.
Y luego están las razones obvias de tratar de importar el valor del texto en una columna entera o insertar un NULL en una columna NOT NULL como lo mencionaron los demás.
Es como el mensaje de error dice "El valor violó las restricciones de integridad para la columna" para la columna "Copia de F2"
Haga que no viole el valor en la tabla de destino. Cuáles son los valores permitidos, los tipos de datos, etc. no se proporcionan en su pregunta, por lo que no podemos ser más específicos al responder.
Para abordar el downvote, no, realmente es como dice: estás poniendo algo en una columna que no está permitido. Podría ser que Faizan señale que está poniendo un NULL en una columna NOT NULLable, pero podría tratarse de una gran cantidad de otras cosas y, como el póster original nunca proporcionó ninguna actualización, nos queda por adivinar. ¿Hubo una restricción de clave externa que violó el inserto? Tal vez hay una restricción de verificación que explotó? Tal vez la columna fuente en Excel tiene un valor de fecha válido para Excel que no es válido para el tipo de datos de fecha / hora de la columna de destino.
Por lo tanto, al mostrar información concreta, la mejor respuesta posible es "no hagas lo que la rompe". En este caso, algo sobre "Copia de F2" es malo para la columna de destino. Danos las definiciones de la tabla, los valores proporcionados, etc., luego puedes respuestas específicas.
Decirles a las personas que hagan una columna NOT NULLable en una NULLable podría ser la respuesta correcta. También podría ser la respuesta más horrible conocida por la humanidad. Si un proceso existente espera que siempre haya un valor en la columna "Copia de F2", cambiar la restricción a NULL puede causar estragos en las consultas existentes. Por ejemplo
SELECT * FROM ArbitraryTable AS T WHERE T.[Copy of F2] = '''';
Actualmente, esa consulta recupera todo lo que se importó recientemente porque Copy of F2 es un indicador de estado mal llamado. Esa información debe alimentarse en el siguiente sistema, así que ... las cuentas pueden ser pagadas. Tan pronto como lo haga de manera que las filas sin procesar puedan tener un valor NULO, la consulta anterior ya no satisface eso. Las facturas no cobran, las colecciones reposan su edificio y ahora está sin trabajo, todo porque no hizo análisis de impacto, etc., etc.
La tabla o vista de Teradata almacena NULL como "?" y SQL lo considera como un carácter o cadena. Esta es la razón principal del error "El valor violó las restricciones de integridad para la columna". cuando los datos se transportan desde el origen de Teradata al destino de SQL. Solución 1: permita que la tabla de destino retenga NULL Solución 2: convierta el ''?'' carácter que se almacenará como algún valor en la tabla de destino.
Suele suceder cuando la opción Permitir nulos está desmarcada.
Solución:
- Mire el nombre de la columna para este error / advertencia.
- Ve a SSMS y encuentra la tabla
- Permitir nulo para esa columna
- Guarde la mesa
- Vuelva a ejecutar el SSIS
Pruebe estos pasos. Funcionó para mí
Como una ligera alternativa a la respuesta de @ FazianMubasher, en lugar de permitir NULL para la columna especificada (que por muchas razones puede no ser posible), también podría agregar una tarea de división condicional a los valores de rama NULL a un archivo de error, o simplemente ignorarlos :