none
Es posible tener un proyecto SSIS con varias configuraciones? RRS feed

  • Pregunta

  • Tengo un proyecto SSIS en Visual Studio, donde tengo varios paquetes que los ejecuto sin problema desde el entorno de Visual Studio, con una configuración basada en Sistemas de archivos, Protection Level Encriptado con Password.

    Para desplegarlo en producción los configuré para que se desplegaran en SQL Server, guardando la configuración en una tabla del SQL Server.

    El problema es que necesito seguir desarrollando y ahora no puedo utilizar el proyecto que configuré para desplegarlo, porque cada vez que se compila se fastidia la tabla de configuración y tuve que hacerme una copia del proyecto, para tener una con la configuración local y otra con la configuración de despliegue en el servidor.

    Esto hay qye hacerlo asi? Es tan molesto trabajar con SSIS?

     

    lunes, 9 de agosto de 2010 6:21

Respuestas

  • Usar para la configuración una tabla de SQL Server es efectivamente un poco molesto porque te intentará usar la misma tabla en desarrollo y en producción, y si no haces nada para irla cambiando, te "machaca" la configuración de producción con los cambios que hagas en desarrollo.

    Una alternativa es usar una configuración "indirecta", donde los datos de la tabla se sacan de una variable de entorno. De esta manera, puedes usar distinta tabla en producción y en desarrollo.

    Otra alternativa es usar para la configuración un archivo XML. De esta manera, aunque se cambien los datos del archivo XML en desarrollo, no tienen por qué cambiarse en producción; basta con que no copies el archivo xml modificado al servidor de producción.

    lunes, 9 de agosto de 2010 6:41
  • No se que quieres decir con que cuando lo compilas se rompe la tabla de configuración, nunca me pasó. Pero por si t e sirve de algo yo lo que hago es

    1.- Creo una configuración en la que solo hay una cadena de conexión a la base de datos de configuración (que a veces es la misma que el origen o el destino de mis paquetes) (Fichero XML)

    2.- Creo una configuración basada en tablas en SQL Server donde están todas mis configuraciones.

    A la hora de desarrollar, el fichero XML de configuración apunta al server de desarrollo, y las cadenas de conexión son, obviamente de desarrollo

    A la hora de poner en producción, simplemente el fichero xml apunta al servidor de producción y todo lo demás.. no hay que tocarlo.

    Lo único que a veces viene bien y no me gusta mucho es que si la ruta donde está el XML de configuración es la misma en desarrollo y producción (C:\Configuraciones, por ejemplo), todo es mucho más simple.

     


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    lunes, 9 de agosto de 2010 6:42
    Moderador

Todas las respuestas

  • Usar para la configuración una tabla de SQL Server es efectivamente un poco molesto porque te intentará usar la misma tabla en desarrollo y en producción, y si no haces nada para irla cambiando, te "machaca" la configuración de producción con los cambios que hagas en desarrollo.

    Una alternativa es usar una configuración "indirecta", donde los datos de la tabla se sacan de una variable de entorno. De esta manera, puedes usar distinta tabla en producción y en desarrollo.

    Otra alternativa es usar para la configuración un archivo XML. De esta manera, aunque se cambien los datos del archivo XML en desarrollo, no tienen por qué cambiarse en producción; basta con que no copies el archivo xml modificado al servidor de producción.

    lunes, 9 de agosto de 2010 6:41
  • No se que quieres decir con que cuando lo compilas se rompe la tabla de configuración, nunca me pasó. Pero por si t e sirve de algo yo lo que hago es

    1.- Creo una configuración en la que solo hay una cadena de conexión a la base de datos de configuración (que a veces es la misma que el origen o el destino de mis paquetes) (Fichero XML)

    2.- Creo una configuración basada en tablas en SQL Server donde están todas mis configuraciones.

    A la hora de desarrollar, el fichero XML de configuración apunta al server de desarrollo, y las cadenas de conexión son, obviamente de desarrollo

    A la hora de poner en producción, simplemente el fichero xml apunta al servidor de producción y todo lo demás.. no hay que tocarlo.

    Lo único que a veces viene bien y no me gusta mucho es que si la ruta donde está el XML de configuración es la misma en desarrollo y producción (C:\Configuraciones, por ejemplo), todo es mucho más simple.

     


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    lunes, 9 de agosto de 2010 6:42
    Moderador
  • 1. En el proyecto de Visual Studio en SSIS "Configuraciones de paquetes", puedo tener varias configuraciones con diferentes nombres? Dos configuraciones con Sistemas de archivos? y otra con SQL Server???

    2. Cómo se le indica al proyecto que utilice una u otra configuración, mientras estoy desarrollando y/o en despliegue?

     

     

    lunes, 9 de agosto de 2010 6:49
  • 1. Si pero no quiere decir que se use una u otra se usan todas

    2.- No es necesario, si tu dices que se usa la configuración que está en c:\configuraciones, el irá ahí a tomar los datos del archivo, lo que ponga dentro es lo único que tiene que ser distinto en desarrollo y producción, es decir.. a producción solo llevarás el paquete, no las configuraciones.

    ¿se entiende?


    Comparte lo que sepas, aprende lo que no sepas (FGG)
    lunes, 9 de agosto de 2010 6:50
    Moderador
  • Hola Miguel,

    Qué tal? Espero que todo vaya bien :)

    Bueno, necesito hablar con usted un poco sobre nuestro foro MSDN en español. Estoy viendo que tu está ayudando mucho en los foros, y me gustaría comprobar si usted tiene algunas sugerencias para nosotros.

    Además, tengo algunas preguntas para hacer para ti.. Por favor, envíe un correo electrónico a v-atpere@microsoft.com, ok?

    Un saludo,


    Átilla Arruda - Microsoft Corporation
    Blog: http://www.atillaarruda.com.br/
    lunes, 9 de agosto de 2010 21:53
    Moderador
  • Hola.

    ¿Se resolvieron tus dudas?


    Alberto López Grande (Visita mi blog en http://qwalgrande.blogspot.es/)
    jueves, 12 de agosto de 2010 17:50
    Moderador