Mes: octubre 2006

Si estás haciendo un paquete de integración con SSIS y tienes un destino SQL Server 2005 lo más lógico (a mí fue lo que me pareció) es usar el componente SQL Server Destination ya que, bueno, pensaba que mejor sería usar el suyo que uno más genérico. Y eso hice, usé SQL Server Destination. Y al ejecutar el workflow todo fue bien. Pero hay una frase que no saldrá de la ley de Murphy por mucho que nos empeñemos y esta frase es: "Si en prueba te funciona, en producción te fallará" y me falló, claro que me falló. Cambié la cadena de conexión del SQL Server 2005 de prueba que tengo en la misma máquina donde ejecuté el paquete SSIS a un SQL Server 2005 en otra máquina que es donde están los datos en producción para que la integración terminara metiendo los datos en la bd correspondiente y ahí empezó el problema.

Tras investigar, probar, buscar y preguntar llegué a una solución: usar OleDB como destino de los datos. Bueno, está bien, es una solución. Si tienes un SQL Server 2005 en una máquina que no es la que ejecuta el paquete SSIS usa un OleDB Destination y te funcionará, claro, con ese componente podrás usar gran variedad de bd como destino de la integración y funcionará.

Pero lo suyo sería usar SQL Server Destination no?. ¿Por qué no trabaja este componente cuando se trata de un SQL Server 2005 en otra máquina?. Si encuentro la solución a la pregunta la postearé aquí y si alguien la tiene y la quiere dejar agradecido estaré ;-).

Tengo que contarlo, de verdad, es una necesidad. Pues ando liado con una integración de unos datos que vienen de una BD Access a un sistema con BD SQL Server 2005 que estamos desarrollando en el Hospital. Esta integración la he hecho con SSIS y la verdad, estaba realmente contento por el resultado … hasta hoy. Si leiste mi post anterior (que "peasso" paquete tengo, niña!) sabrás de que hablo. Bueno, de todas formas lo resumo.

Imagínate una BD Access para realizar Informes de Alta de pacientes en un hospital. Tiene un formulario con una serie de cajas de texto para almacenar la información de un informe de alta como son: anamnesis, antecedentes, exploraciones, diagnósticos, tratamiento, etc. Y una caja de texto con nombre "Nota Médico de Cabecera".

Cuando estabamos viendo cómo mapeábamos los campos pensamos que este último campo no sería necesario integrarlo ya que nuestro sistema con BD SQL Server no registra nada sobre el médico de cabecera que puede tener un paciente y consideramos que no era necesario.

Hasta aquí bien. Hacemos la integración y todos los registros (bueno excepto alguno que no podía cumplir las modificaciones) pasaron de la BD Access a SQL Server 2005. Yeahhh!!! toda la información anterior estará en el nuevo sistema. Vale, venga, vamos a hablar con la secretaria que hace los informes de alta del servicio cuya BD Access habíamos migrado, y ….

– Secretaria: EHHHH!!!, este informe de alta sale en blanco y en la BD Access está relleno.

– Miguel: ¿Cómo? ¿qué?, ¡¡IMPOSIBLE!!. (lo he hecho con SSIS, es imposible lo que me dice esta chica)

– Secretaria: Que sí, que sí!!!, ya verás …

y abre su BD Access, busca al paciente, y me enseña el informe de alta.

¡¡NO ME LO PODÍA CREER!!

Daba igual que en la BD Access hubiera una caja de texto para cada apartado del informe de alta, daba igual que las cajas estuvieran en orden para que el informe se rellenara de manera adecuada, todo daba igual …

¡¡Todo el informe estaba en la caja de texto "Nota Médico de Cabecera"!! – INCREIBLE!!!

Claro, ni SSIS, ni ISSS, ni SISI, ni SSSI, ni la madre que lo p… 🙂

Conclusión:

A pesar de que cada día contamos con nuevas herramientas, a pesar de que informáticamente hablando casi todo es posible, a pesar de todos los pesares, como el médico de cabecera quiera, te dolerá la cabeza.

Ahí queda eso!!!.

Jajaja, si es que aún me rio cuando recuerdo la situación. La frase del post se la dije a mi compi, y de pronto. Y es que me salió sin más, de alegría, de ver que funcionaba ;-). Bueno bueno, que esto es un blog de informática y no la web del marqueze. Y es que ahora estoy liado con una importación de datos de una base de datos Access (sí sí, de un informático, sí hombre!!, de esos que ponen todos los campos memo, los nombra con espacios en blanco y no pone claves a las tablas) a una bd de SQL Server 2005 de un proyecto que tenemos en el Hospital donde trabajo. Y como no tenía más remedio que meterme en esa importación pues me dije: "Tío, una buena oportunidad para hacer cosillas con Integration Services", y el resultado fue esa frase del post. Es mi primer paquete de Integration Services, y creo que no será el último, así que igual escribo alguna cosa de mis peripecias con estos servicios. No trabajé con DTS ni con ningún sistema de transformación de datos previamente así que no puedo hacer una valoración de SSIS con respecto a otros sistemas, lo que sí puedo decir es: ¡¡Qué "peassso" paquete tengo, niña!! :-).

Y dejo aquí una cosilla por si alguien empieza con esta herramienta y que me ha pasado y ha sido, quizás, el mayor problemilla que he tenido, de momento. Cuando ejecutaba me daba un error en el Data Flow y el destino SQL Server se ponía en rojito. Viendo en la ventana "Log Events" (de mucha utilidad) observé un error que se producía efectivamente en el destino. Descubrí finalmente que se debía a la propiedad timeout de este componente que, por defecto, viene establecida a 30, es decir, a los 30 segundos desde el inicio de la ejecución este componente genera un timeout si no tiene datos. Y no los podía tener puesto que mis tareas de modificaciones tardaban más de 30 seg. Por tanto, para evitar este error (que finaliza la ejecución) se puede aumentar este tiempo o simplemente ponerlo a 0 para que no salte.

Por cierto, que bueno es Fito!! (lo escuchaba en el momento de escribir el post)