Por: Koen Verbeeck | Actualizado: 2018-07-31 | Comentarios (13) | Relacionado: Más > Desarrollo de Integration Services
Problema
SQL Server Data Tools (SSDT) es el entorno de desarrollo para crear y mantener paquetes y proyectos de Integration Services (SSIS). Históricamente, no había compatibilidad hacia atrás, lo que significa que con una versión más reciente de SSDT, no se podían crear paquetes SSIS para una versión anterior de SSDT. Desde la versión de SQL Server 2016,SQL Server Data Tools soporta la compatibilidad hacia atrás hasta SQL Server 2012. Este consejo explica la nueva característica.
Solución
Introducción
Históricamente, cada versión de SQL Server tenía una versión adjunta de un entorno de desarrollo de inteligencia empresarial. Siempre se trataba de un conjunto de plantillas instaladas en Visual Studio o, si Visual Studio no estaba ya presente, de una ventana de Visual Studio sólo capaz de manejar proyectos de BI. Con esta herramienta, se podían desarrollar proyectos de Integration Services, Analysis Services y Reporting Services.Inicialmente, esta herramienta se llamaba Business Intelligence Development Studio o BIDS.En SQL Server 2012, pasó a llamarse SQL Server Data Tools. Sin embargo, Microsof tenía también otro producto llamado SQL Server Data Tools; con esta herramienta se podían crear y gestionar proyectos de bases de datos de SQL Server. La herramienta de BI estaba disponible en los medios de instalación de SQL Server, mientras que la herramienta de base de datos era una descarga independiente (y gratuita). Debido a que esto causó bastante confusión, SSDT pasó a llamarse SQL ServerData Tools for Business Intelligence o SSDT-BI. Desde SQL Server 2016, las herramientas de BI están ahora acopladas con la herramienta de base de datos y el conjunto de herramientas se llama ahora SQL Server Data Tools o SSDT. Una visión general:
- SQL Server 2005 – Visual Studio 2005 (BIDS)
- SQL Server 2008 y 2008R2 – Visual Studio 2008 (BIDS)
- SQL Server 2012 – Visual Studio 2010 (SSDT, disponible en el medio de instalación de SQL Server) o Visual Studio 2012 (SSDT-BI, disponible como descarga independiente)
- SQL Server 2014 – Visual Studio 2013 (SSDT-BI, disponible como una descarga separada)
- SQL Server 2016 – Visual Studio 2015 (SSDT, disponible como una descarga separadae incorpora proyectos de bases de datos también)
- SQL Server 2017 – Visual Studio 2015 o Visual Studio 2017 (SSDT)
El problema aquí era que SSIS no tenía ningún soporte para la compatibilidad hacia atrás.Por ejemplo, si querías desarrollar paquetes para SQL Server 2008, necesitabas VisualStudio 2008. Si querías desarrollar para SQL Server 2014, necesitabas Visual Studio2013. Con Visual Studio 2013, no se podían desarrollar proyectos SSIS para SQL Server2008 ni para ninguna otra versión de SQL Server, excepto para SQL Server 2014. Esto significaba que si trabajaba con varias versiones de SSIS, terminaba con muchas versiones diferentes de Visual Studio en su máquina de desarrollo.
Las últimas versiones de SSDT (desde SQL Server 2016) resuelven estos problemas: al introducir la compatibilidad hacia atrás, puede utilizar una sola versión de SSDT para desarrollar y mantener versiones de proyectos SSIS desde 2012 hasta 2017 y posteriores. Es importante tener en cuenta que SSAS y SSRS soportan la compatibilidad hacia atrás desde hace bastante tiempo.
SSIS y la compatibilidad hacia atrás
El resto de este consejo fue escrito utilizando la versión SSDT de Visual Studio 2015, junto con SQL Server 2016. Todos los consejos que se dan en este consejo son válidos también para versiones posteriores.
En primer lugar, necesitamos instalar la última versión de la versión preliminar de Visual Studio 2015SSDT. Cuando se abre el medio de instalación de SQL Server 2016, se puede encontrar un enlace a la página de descarga. También contiene un enlace a la página de descarga de SQL Server Management Studio (SSMS), ya que ahora también es una descarga independiente.
Crear un nuevo proyecto
Cuando se añade un nuevo proyecto, se puede ver que ahora es posible crear proyectos de base de datos y proyectos de BI también en SSDT.
En las propiedades del proyecto, puede establecer la versión SSIS de destino que SSDT utilizará para este proyecto.
La versión de destino por defecto es SQL Server 2016 (en versiones posteriores de SSIS será la versión más reciente de SQL Server). SQL Server 2014 y SQL Server 2012 también son compatibles, mientras que las versiones más antiguas (2005 y 2008) no lo son. Si tiene proyectos más antiguos que SQL Server 2012, tendrá que actualizarlos primero antes de poder utilizar la última versión de SSDT.
Una vez establecida la versión de destino, la caja de herramientas de SSIS se adaptará en consecuencia. Por ejemplo, en SQL Server 2016 hay nuevas tareas de Hadoop disponibles y puede descargar tareas deAzure del paquete de características deAzure.
Al establecer la versión de SQL Server 2014, todas esas nuevas tareas desaparecerán de la caja de herramientas de SSIS. Lo mismo ocurre con las transformaciones de flujo de datos introducidas en SQL Server 2016.
Al cambiar la versión de un proyecto, obtendrá una advertencia de que los paquetes existentes podrían cambiarse:
Sin embargo, si utiliza la funcionalidad de SQL Server 2016, obtendrá un error después de establecer la versión de destino a una versión anterior al abrir el paquete:
El paquete se sigue abriendo, pero las tareas, transformaciones o gestores de conexión ofensivos pueden desaparecer, o no se puede abrir un editor. Es posible que el cambio a SQL Server 2016 no resuelva el problema: el objeto puede seguir estando roto. En ese caso, no hay otra opción que eliminar el objeto y añadirlo de nuevo.
En el momento de escribir este artículo, existen un par de errores al cambiar entre versiones de destino. Puedes encontrar una lista en la entrada del blog de MSDN¿Qué hay de nuevo en SSIS 2016 RC0? Es posible que algunos de ellos ya estén solucionados cuando leas esto.
Cuando tienes tus propios componentes personalizados en SSIS, tienes que dar algunos pasos extra para que funcionen con la propiedad de la versión de destino. El MVP de SQL Server Joost vanRossum explica cómo se puede hacer esto en su entrada del blogSwitching Target Server Versions for custom components.
Añadir paquetes existentes al proyecto
Cuando se añade un paquete SSIS existente de una versión anterior al proyecto- por ejemplo un paquete SSIS 2012 a un proyecto 2016- el paquete se actualizará para que coincida con la versión de destino.
Cuando las versiones coinciden, no se produce ninguna actualización, por supuesto, el paquete se añade directamente al proyecto. También puede añadir paquetes de una versión superior al proyecto, SSIS intentará degradarlos.
Las pruebas demuestran sin embargo que no siempre se puede confiar en este mensaje. Incluso con un successmessage, el paquete puede ser roto si se utiliza SQL Server 2016 sólo componentes.
Abrir un proyecto existente
Cuando se utiliza SSDT 2015 para abrir un proyecto creado con una versión anterior de SSDT, el asistente de actualización se pondrá en marcha automáticamente. Esto significa que todos los paquetes se actualizan a SQL Server 2016.
Aunque todavía puede degradar el proyecto a la versión anterior, pasar por el proceso de actualización es tal vez algo que no desea. Como alternativa, puede editar el archivo del proyecto y añadir la siguiente línea:
Esto hará que SSDT 2015 omita el asistente de actualización y abra directamente el proyecto con la versión de destino correcta. Para SQL Server 2014, se cambia SQLServer2012 por SQLServer2014, por supuesto. Aunque esta solución parece funcionar, la edición manual del XML del archivo del proyecto no es realmente compatible. Mi consejo es crear un nuevo proyecto vacío, establecer la versión de destino y luego empezar a añadir paquetes.
Partes de flujo de control
Las partes de flujo de control se introducen en el consejoIntroducción a las plantillas de flujo de control de SQL Server Integration Services 2016 (se han renombrado de plantillas a partes). Sorprendentemente, todavía puede trabajar con partes de flujo de control si su versión de destino no es SQL Server2016. Esto es posible porque son una característica en tiempo de diseño y no influyen en el funcionamiento real de los paquetes. En este ejemplo, he creado un nuevo proyecto con la versión de destino establecida en SQL Server 2014. He creado una parte de flujo de control simple y la he añadido al paquete.
La depuración del paquete no es un problema.
Y también puede ejecutar el paquete dentro de un catálogo SSIS de SQL Server 2014:
Conclusión
La propiedad Target Server Version introduce compatibilidad con versiones anteriorespara el proyecto SSIS en SSDT 2015. Con esta nueva capacidad, se ha solucionado finalmente una antigua llaga de SSIS: puede utilizar una sola versión de Visual Studio para gestionar susdiferentes proyectos SSIS. Se recomienda establecer la versión del servidor al inicio del proyecto y no cambiarla con demasiada frecuencia, ya que puede dar lugar a problemas.La buena noticia es que con SSDT 2015 y posteriores, ¡también puede utilizar partes de flujo de control en sus proyectos más antiguos!
Siguientes pasos
- Para obtener más información sobre las diferentes versiones de SQL Server Data Tools:
- La evolución de SSDT
- SQL 2014 CTP1, ¿dónde está mi BIDS?
- Para más información sobre las partes del flujo de control, echa un vistazo al consejoIntroducción a las plantillas de flujo de control de SQL Server Integration Services 2016.
- Para más consejos sobre SQL Server 2016, puedes utilizar esta visión general.
Última actualización: 2018-07-31
Acerca del autor
Koen Verbeeck es un profesional de BI, especializado en la pila de Microsoft BI con un amor particular por SSIS.Ver todos mis consejos
- Más consejos de Business Intelligence…