paquetes - paquete ssis funciona manualmente pero falla como sql job

Conexión SSIS no encontrada en el paquete (20)

Soy un poco nuevo en la programación de SSIS y tengo algunos problemas para implementar un paquete de SSIS.

Este paquete se ejecuta correctamente en mi PC, hace todo lo que necesita hacer ... pero cuando lo implemento no puedo encontrar las cadenas de conexión.

Aquí está el error:

Código: 0xC001000E Fuente: Descripción: No se encontró la conexión "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}". Este error es generado por la colección Connections cuando no se encuentra el elemento de conexión específico. Error final
Error: 2012-08-09 00: 21: 06.25 Código: 0xC001000E Fuente: Descripción del paquete: No se encuentra la conexión "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}". Este error es generado por la colección Connections cuando no se encuentra el elemento de conexión específico. Error final
Error: 2012-08-09 00: 21: 06.25 Código: 0xC001000E Fuente: Descripción del paquete: No se encuentra la conexión "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}". Este error es generado por la colección Connections cuando no se encuentra el elemento de conexión específico. Error final
Error: 2012-08-09 00: 21: 06.25 Código: 0xC00291EB Origen: Ejecutar tarea de SQL Ejecutar tarea de SQL Descripción: Administrador de conexión "{DA7CD38D-F6AA-4B06-8014-58BEE5684364}" no existe Error final
Error: 2012-08-09 00: 21: 06.25 Código: 0xC0024107 Fuente: Ejecutar SQL Descripción de la tarea: Hubo errores durante la validación de la tarea. Error final DTExec: la ejecución del paquete devolvió DTSER_FAILURE (1). Iniciado: 00:21:04 Terminado: 00:21:06 Transcurrido: 1.888 segundos. La ejecución del paquete falló. El paso falló.

Determiné que este problema era un administrador de conexión dañado al identificar la conexión específica que estaba fallando. Estoy trabajando en SQL Server 2016 y he creado el catálogo SSISDB y estoy implementando mis proyectos allí.

Aquí está la respuesta corta. Elimine el administrador de conexión y luego vuelva a crearlo con el mismo nombre. Asegúrate de que los paquetes que usan esa conexión todavía estén conectados correctamente y deberías estar listo. Si no está seguro de cómo hacerlo, he incluido el procedimiento detallado a continuación.

Para identificar la conexión corrupta, hice lo siguiente. En SSMS, abrí la carpeta de catálogos de servicios de integración, luego la carpeta SSISDB, luego la carpeta para mi solución, y hasta que encontré mi lista de paquetes para ese proyecto.

Al hacer clic derecho en el paquete que falló, ir a informes> informes estándar> todas las ejecuciones, seleccionar la última ejecución y ver el informe "Todos los mensajes" pude aislar qué conexión estaba fallando. En mi caso, el administrador de conexión a mi destino. Simplemente eliminé el administrador de conexión y luego volví a crear un nuevo administrador de conexión con el mismo nombre.

Posteriormente, entré en mi paquete, abrí el flujo de datos, encontré que algunos de mis destinos se habían iluminado con la X roja. Abrí el destino, volví a seleccionar el nombre de conexión correcto, volví a seleccionar la tabla de destino y verifiqué la Las asignaciones seguían siendo correctas. Tenía seis destinos y solo tres tenían la X roja, pero hice clic en todos ellos y me aseguré de que todavía estuvieran configurados correctamente.

El paquete funciona bien el viernes, regístrese en TFS y váyase a casa. Ábrelo el lunes, obteniendo errores por todas partes. "la variable del administrador de conexión $ project._connectionstring no se encontró en la colección de variables".

I rtclicé-edité la conexión y probé la conectividad, no funciona ningún problema; em. El ConnMnger está en la lista de administradores de conexión en la solución. Cuando abra el objeto TARGET conectado a este administrador de conexión, y haga clic en MAPPINGS, aparecerá el error anterior. No hay referencia a las variables del administrador de conexión en ningún lugar de la asignación.

Resulta que, para corregir esto, debe hacer clic derecho en el administrador de conexión en la ventana Administrador de conexión y elegir PARAMETERIZAR. Rellene las opciones según sea necesario -

PROPIEDAD: ConnectionString Use el parámetro Exisgint: $ Project :: ConnMgrName_ConnectionString O Cree un nuevo parámetro de PA: siga las opciones

Una vez que este administrador de conexión está parametrizado, todo funciona. A pesar de que Conn Manger existía en la pestaña Conn Manger, Conn Mgr ya está en la lista del Explorador de soluciones Y no funcionó ningún problema 2 días antes.

Impar. Lo que sea. Microsoft es Microsoft. SQL Server siendo SQL Server. Elige tu veneno.

Espero que esto ayude a la siguiente persona a ahorrar tiempo.

El valor de conexión en el trabajo parece ser sensible a mayúsculas y minúsculas.

En mi caso, descubrí que el problema era un proveedor de registro configurado previamente que apunta a una conexión antigua que ya no se usa. Para resolver el problema, haga clic en la pestaña del Explorador de paquetes y luego haga clic en Proveedores de registro y elimine el Proveedor de registros obsoleto. Espero que esto ayude a alguien.

En mi caso, podría resolver esto de una manera más fácil. Abrí el archivo x.dtsConfig, y por una razón desconocida, este archivo no estaba en el formato estándar, por lo que ssis no pudo reconocer las configuraciones. Afortunadamente, había hecho una copia de seguridad del archivo anteriormente, así que tuve que copiarlo en la carpeta original y todo estaba funcionando de nuevo.

En mi caso, una de las tareas del controlador de eventos apuntaba a una conexión anterior que se eliminó, al eliminar la tarea del controlador de eventos no utilizada se solucionó el problema. ¡Termino abriendo el paquete en formato XML para entender que el problema es con la tarea del controlador de eventos!

Esta solución funcionó para mí:

Vaya a SQL Server Management Studio, haga clic con el botón derecho en el paso que falla y seleccione Propiedades -> Registro -> Eliminar el proveedor de registros, y luego vuelva a agregarlo

Esto parece suceder también cuando usa el nuevo concepto de "Administrador de conexión compartida" de SSIS 2012 en el que los administradores de conexión no están definidos dentro de su paquete, sino en el proyecto de Visual Studio y solo se hace referencia en el paquete. Al ejecutarlo a través del Agente SQL o DTEXEC aparece el mismo mensaje de error.

No he encontrado una solución para eso todavía, pero me encantaría recibir comentarios si alguien lo hubiera experimentado antes.

Generalmente, cuando SSIS parece estar quejándose irracionalmente de una conexión aparentemente buena, es porque trato de definir la Conexión directamente usando una variable de paquete en lugar de hacerlo a través de un Connection Manager. Ejemplo: hoy tuve una tarea de servicio web en la que cometí el error de crear directamente una expresión que define su propiedad "Conexión" en términos de una variable de paquete que contenía la URL del servicio web. Sin embargo, tenga en cuenta que una conexión no es lo mismo que una ConnectionString. Así que cuando miré la tarea, buscaba en todo el mundo que tenía todo lo válido, porque mostraba una URL perfectamente válida como "Conexión". El problema es que la conexión no puede ser una cadena; debe ser un administrador de conexión.

Gracias por publicar este problema.

Una resolución: abra el paquete en formato XML a través del explorador de Windows, localice el GUID para el administrador de conexión que no se puede encontrar. En mi caso, fue una conexión de EventHandler que estaba dañada y que estaba dañada. Este mismo administrador de conexión se usó en el flujo de control, pero de alguna manera no se corrompió allí, por lo que no fue obvio para el usuario a través de la interfaz de usuario. Dado que el XML apuntaba a un administrador de conexión de controlador de eventos, abrí la pestaña del controlador de eventos en la interfaz de usuario e inmediatamente mostraba el maravilloso RED X en la fuente y los destinos que hacían referencia al ID del administrador de conexión dañado. Lo reubicé en el administrador correcto, reconstruí el paquete y lo guardé. Bueno para ir.

La clave fue abrir el paquete en formato XML y ubicar el GUID en el código para ver dónde fallaba. Si no podía encontrar una referencia válida en la interfaz de usuario, cambiaría el nombre de la conexión XML a otro GUID conocido dentro del XML y luego ingresaría a la interfaz de usuario y la volvería a ubicar, o la eliminaría por completo.

Buena suerte.

Llegué un poco tarde a la fiesta, pero me encontré con este hilo mientras experimentaba los mismos errores y encontré una resolución diferente.

Al crear un paquete SSIS 2012, en la ventana del Explorador de soluciones verá la carpeta Administradores de conexión en el nivel del proyecto. Este parece ser el lugar más lógico para crear una conexión, y debe utilizarse al crear una conexión que pueda ser utilizada por cualquier paquete en el proyecto. Se incluye a nivel de proyecto y no a nivel de paquete.

Al ejecutar mi paquete dtsx usando dtexec, recibí los mismos errores que se muestran arriba. Esto se debe a que la conexión no está incluida en el paquete (solo el proyecto). Mi solución fue ingresar al diseñador de paquetes, y luego en la ventana de Connection Manager, hacer clic con el botón derecho en la conexión a nivel de proyecto (que se muestra con el prefijo "(proyecto)") y elegir "Convertir a conexión de paquete". Esto integrará la conexión en el paquete dtsx real. Esto alivió mi problema.

Lo que hice para resolver este problema fue simple. Tuve que cambiar mi nombre de SQL Server para que respondiera a la etiqueta (localhos). Después de eso cambié todas las conexiones en el SSIS y reconstruí la solución ... funcionó. espero que te ayude

Los comentarios anteriores sobre la eliminación o eliminación de una conexión son absolutamente una posibilidad. Pero también puede obtener este error cuando intenta invocar un paquete que usa conexiones a nivel de proyecto (en lugar de conexiones a nivel de paquete).

Si está utilizando conexiones a nivel de proyecto y aún desea usar dtexec, no se preocupe, hay una manera. No recomendaría convertirlos en conexiones de nivel de paquete (suponiendo que las haya creado como conexiones de nivel de proyecto por una buena razón).

Deberá implementar su proyecto SSIS. Su servidor SSIS deberá tener un catálogo creado ( https://msdn.microsoft.com/en-us/library/gg471509.aspx ). Una vez que tenga el catálogo, en su proyecto SSIS, seleccione Proyecto-> Implementar y siga el asistente. El resultado será un archivo * .ispac generado en su carpeta de soluciones SSIS / bin / Development

Ahora para el comando money, en lugar de invocar su paquete con un simple: dtexec.exe / f "package.dtsx"

en su lugar, llámelo de esta forma: dtexec.exe / project "<...> / project.ispac" / package "<...> / package.dtsx"

El archivo ispac tiene la información de conexión a nivel de proyecto que se necesita para ejecutar su paquete, ¡y debe configurarlo!

Otra permutación que causa un problema en 2008R2 es la configuración del paquete. Había establecido una propiedad para guardar / configurar desde un archivo dtsconfig y luego eliminé la conexión a la que hacía referencia. La resolución fue simple, edite la configuración y anule la selección del objeto no deseado y luego seleccione la propiedad apropiada para el administrador de conexión cuyo nombre se ha cambiado. El error no se repitió después de guardar, cerrar y volver a abrir el proyecto. :-)

Para el paquete desarrollado en Visual Studio 2015, encontré que debo proporcionar un valor para el parámetro (que sería el caso cuando implementa o ejecuta en un servidor diferente) que establece la cadena de conexión del administrador de conexión en lugar de usar el valor de tiempo de diseño. Esto suprimirá el mensaje de error. Creo que esto podría ser un error.

dtexec /project c:/mypath/ETL.ispac /package mypackage.dtsx /SET /Package.Variables[$Project::myParameterName];"myValueForTheParameter"

Probé esto sin o sin parametrizar la cadena de conexión, que está en el nivel del proyecto. El resultado fue el mismo: es decir, tengo que establecer el valor del parámetro, incluso si no se usó.

Recibí este error al intentar abrir un proyecto SSDT 2010 / SSIS 2012 en VS con SSDT 2013. Cuando abrió el proyecto, solicitó migrar todos los paquetes. Cuando permití que continuara, todos los paquetes fallaron con este error y otros. Descubrí que al omitir la conversión y simplemente abrir cada paquete individualmente, el paquete se actualiza al abrirse, y se convirtió correctamente y se ejecutó correctamente.

Tuve el mismo problema en mi caso, la causa era que la conexión no estaba incorporada y la incompatibilidad del Cliente Oracle.

SOLUCIÓN:

Mi entorno: SQL Server 2014 64bit Oracle Client 32 bit

Para incluir / insertar conexión
- paquete abierto
- haga clic derecho en la conexión
- Seleccione la opción "Convertir a proyecto"
para SQL SSIS Catálogo / Programación de trabajos, configure la configuración, siga los pasos en la imagen
- Justo en ''SQL JOB-> Step "o" SSIS Catalog -> Package -> Execute "y seleccione" Properties "
- Seleccione Configuración -> pestaña Avanzado
- Comprobado el tiempo de ejecución de 32 bits

Intenté publicar imágenes detalladas paso a paso, pero no lo permite debido a su reputación. Espero que luego pueda actualizar este post.

Tuve el mismo problema y ninguno de los anteriores lo eliminó. Resulta que había una tarea SQL antigua que estaba deshabilitada en la esquina inferior derecha de mi ssis que realmente tenía que buscar para encontrar. Una vez que borré esto todo estuvo bien

Yo tuve el mismo problema.

Uso los administradores de conexión a nivel de proyecto y mis paquetes se ejecutan correctamente en SSDT, pero cuando los implementé y los ejecuté a través de un trabajo con el agente del servidor SQL, obtengo errores de "Conexión no encontrada".

Así que implemento el proyecto y luego el problema se resolvió, cuando usa administradores de conexión a nivel de proyecto pero solo implementa un paquete de ese proyecto, y llama al paquete a través del agente del servidor SQL, no pudo reconocer a sus administradores de conexión, por lo que debería determinar el paquete. administradores de conexión de nivel o primero debe implementar su proyecto.

Parece que su paquete ssis apunta a alguna otra conexión que podría haber sido deleted o renamed Intente abrir los componentes SSIS y apunte a la conexión correcta que hay en su administrador de conexión.

Ocurre cuando copiamos los componentes del paquete SSIS para crear un nuevo paquete o porque cambiamos el nombre de las conexiones o puede que todavía haya componentes que estén usando la conexión anterior definida en su archivo de configuración xml (en su caso, intente verificar la tarea de ejecución de SQL que es error de lanzamiento). Si está utilizando XML para configuración, intente desplegar el nuevo.