proveedores - Usar SQL dinámico en una fuente OLE DB en SSIS 2012
no se admiten consultas heterogéneas ni el uso de proveedores ole db en modo de fibra (2)
Entonces, le pido por amabilidad, ¿por qué en la tierra verde de Dios está usando una tarea de flujo de datos de SSIS para manejar datos dinámicos de origen como este?
La razón por la que está teniendo problemas es porque está pervirtiendo cada propósito de una tarea de flujo de datos de SSIS:
- para extraer una fuente conocida con metadatos conocidos que pueden ser tipificados y almacenados en caché en tiempo de diseño
- ejecutar un proceso conocido con transformaciones directas (e idealmente asincrónicas)
- tomar los datos transformados y cargarlos en un destino conocido también con metadatos conocidos
Está bien tener fuentes de datos parametrizadas que traigan datos diferentes. Pero tener que traer metadatos completamente diferentes cada vez sin congruencia entre los diferentes conjuntos es, francamente, ridículo, y no estoy del todo seguro de querer saber cómo manejaste todos los metadatos de tu columna en el paquete de trabajo de 2008.
Es por eso que quiere que agregue un CONJUNTO DE RESULTADOS a la consulta de SSIS, por lo que puede generar algunos metadatos. No hace esto en tiempo de ejecución, ¡no puede! Tiene que tener un conjunto conocido de columnas (porque alias todas ellas en variables compiladas de todos modos) para trabajar con. Espera las mismas columnas cada vez que ejecuta esa tarea de flujo de datos: exactamente las mismas columnas, hasta los nombres, los tipos y las restricciones.
Lo que conduce a una (terrible, terrible) solución: simplemente pegue todos los datos en una tabla temporal con Column1, Column2 ... ColumnN y luego use la misma variable que está usando como parámetro de nombre de tabla para bifurcar condicionalmente su código y hacer lo que quieras con las columnas.
Otra solución más sensata sería crear una tarea de flujo de datos para cada una de sus tablas de origen, y usar su parámetro en una restricción de precedencia para simplemente elegir qué tarea de flujo de datos debería ejecutarse.
Para una solución que no está bien adaptada para un ETL listo para usar, también debe considerar simplemente hacer su propia versión en C # o una tarea de secuencia de comandos en lugar de la tarea de flujo de datos proporcionada por SSIS.
En resumen, por favor no hagas esto. ¡Piensa en los niños (paquetes)!
Tengo un proceso almacenado como el texto del comando SQL, al que se le pasa un parámetro que contiene un nombre de tabla. El proceso devuelve datos de esa tabla. No puedo llamar directamente a la tabla como fuente de OLE DB porque es necesario que ocurra algo de lógica de negocios en el conjunto de resultados en el proceso. En SQL 2008, esto funcionó bien. En un paquete actualizado de 2012 aparece "Los metadatos no pudieron determinarse porque ... contiene SQL dinámico. Considere utilizar la cláusula WITH RESULT SETS para describir explícitamente el conjunto de resultados".
El problema es que no puedo definir los nombres de los campos en el proceso porque el nombre de la tabla que se pasa como parámetro puede tener un valor diferente y los campos resultantes pueden ser diferentes cada vez. ¿Alguien tiene este problema o tiene alguna idea? He intentado todo tipo de cosas con SQL dinámico utilizando "dm_exec_describe_first_result_set", tablas temporales y CTE que contiene WITH RESULT SETS, pero no funciona en SSIS 2012, el mismo error. El contexto es un problema con muchos de los enfoques dinámicos de SQL.
Esto es lo último que intenté, sin suerte:
DECLARE @sql VARCHAR(MAX)
SET @sql = ''SELECT * FROM '' + @dataTableName
DECLARE @listStr VARCHAR(MAX)
SELECT @listStr = COALESCE(@listStr +'','','''') + [name] + '' '' + system_type_name FROM sys.dm_exec_describe_first_result_set(@sql, NULL, 1)
exec(''exec(''''SELECT * FROM myDataTable'''') WITH RESULT SETS (('' + @listStr + ''))'')
He usado CozyRoc Dynamic DataFlow Plus para lograr esto.
Usando tablas de configuración para construir las sentencias SQL Select, tengo un paquete SSIS único que carga datos de Oracle y Sybase (o cualquier fuente OLEDB) a MS SQL. Algunos de los conjuntos de resultados están en millones de filas y el rendimiento es excelente.
En lugar de escribir un nuevo paquete cada vez que se necesita una nueva tabla, esto se puede configurar en minutos y ejecutar en un paquete existente robusto y probado previamente.
Sin él, me hubiera gustado escribir cientos de paquetes.