2008-10-24 30 views
19

Estoy tratando de hacer que nuestros paquetes de SQL Server Integration Services sean tan portátiles como sea posible y lo único que impide que la ruta a la configuración sea siempre una ruta absoluta, lo que hace que las pruebas y la implementación sean un dolor de cabeza. ¿Hay alguna sugerencia para hacer esto más manejable?¿Es posible usar rutas relativas para los paquetes SSIS de los archivos dtsConfig?

Otro problema es cuando otro desarrollador obtiene el paquete fuera del control de origen, la ruta es específica para el equipo de desarrollo.

Respuesta

13

Si está intentando ejecutar sus paquetes utilizando Visual Studio, la ruta del archivo de configuración estará codificada allí. Entonces, si mueve su proyecto, necesitará cambiar la ruta en la configuración del paquete. Para evitar esto, puede usar la opción Variable de entorno para almacenar la ruta del archivo de configuración. Entonces solo necesitarás cambiar eso.

Para pruebas e implementación, sin embargo, probablemente debería usar la utilidad dtexec para ejecutar sus paquetes. Haga algunos archivos por lotes para eso. Preferiblemente uno para cada ambiente diferente. Aquí la ruta del archivo de configuración puede ser relativa.

dtexec /File Package.dtsx /Conf configuration.dtsConfig" 

Esto es si sus paquetes están en el sistema de archivos. También puede almacenarlos en SQL Server. También puede almacenar su configuración en SQL Server, que puede proporcionar flexibilidad.

+3

1 para variable de entorno. Es una gran solución para múltiples desarrolladores. –

+6

Tenga en cuenta que si ha marcado SSIS -> "Habilitar configuraciones de paquetes" ignorará lo que puso en el parámetro/Conf y usará lo que está codificado en el paquete. – NickHeidke

2

Después de varias horas tratando de hacer este trabajo he encontrado una solución here (no el mejor, pero funciona)

  1. localizar los archivos de configuración (archivos dtsconfig) en el mismo directorio que el archivo de solución (archivo .sln)
  2. SIEMPRE abra su solución haciendo doble clic en el archivo de solución (archivo .sln). Esto configurará la 'carpeta de trabajo' para que esté donde reside la solución, su archivo de configuración se leerá correctamente

De lo contrario, las rutas relativas no me funcionaron.

+1

El enlace no está funcionando ahora –

0

Mi truco de la norma para este tipo de problemas están mapeando las unidades.

O usando mapped network drive o usando Subst (ambos métodos son intercambiables).

p. Ej. Asigne la ubicación de su paquete a N: \ dentro de las rutas de uso del paquete usando N: \ MyParentPackage.dtsx, N: \ MyChildPackage.dtsx. Los paquetes pueden estar en unidades totalmente diferentes en diferentes carpetas en diferentes máquinas, funcionará una vez que asigne la ubicación del paquete a N: \

Normalmente pongo una secuencia de comandos junto a los archivos del proyecto para mapear la unidad, que mapea la unidad para que pueda ejecutarse fácilmente antes. Una vez, si está usando subst en VISTA - Win8, asócielo para elevado y no elevado.

Uso el mismo enfoque para referencias de archivos en proyectos de Visual Studio. Solo un problema con este enfoque, lo usas para resolver demasiados problemas en tu entorno de desarrollo y se te acabarán las letras de las unidades.

Cuestiones relacionadas