SSIS Data Conversion Que pasó? Antes eras Chévere!!!!

Buenas buenas :)

bien, el día de hoy les hablaré de un componente de SSIS llamado Data Conversion. Como bien saben en algunos casos, nuestros hermosos clientes tienen en sus bases de datos tablas que tienen columnas, que tienen tipos de datos (quetienen, que tienen, que tienen...).

Lo normal es que esos tipos de datos tengan un manejo natural de algunas cosas que para uno de developer son muy obvias. Ejemplo, si tengo un UnicodeString de lenght 255 y tengo que meterlo a un string de 50, bueno, es solo usar el componente para convertir, cambiar el tamaño y todos somos felices.

Bueno, SSIS en su maratón por ponerme a pensar, me empezó a generar errores en este componente.

Después de mucho meditar, pensar y a punto de arrojar el pc por la ventana, me dí cuenta que el error estaba al realizar exactamente ese tipo de conversión. Ojo, no siempre sucede, pero en caso que apareciera el error descrito en la segunda imágen o incluso cuando sale el horroroso Exception from HRESULT: 0xC0047020 debería ser este caso.

Bien, solución? decidí quitar el Data Conversion y lo cambié por un Derived Column. Para la conversión de datos usé el Cast, dándole el tipo de dato requerido y el lenght correcto. El resultado fué un error por truncamiento. Que se hace en este caso? poner un Substring al campo

Con esto solucionamos el problema. Si se dan cuenta incluso el Warning desapareció.

Bueno. En algunos casos el mejor camino a encontrar el error que aparece (cuando no es específico) lo mejor es ver los warnings. Diría un amigo mío, "los warnings no son chisme" estos si bien no nos dicen que es el error en sí, nos pueden ayudar mucho a encontrarlo, sobretodo en SSIS ya que este no posee un proceso de debugging (al cual los developers estamos acostumbrados).

Como una recomendación, si estás empezando con SSIS, es muy importante, que llegues a un nivel de ver campo por campo de las fuentes y destino de tu integración, esto con el fin de que tenga una coherencia el proceso y no tengas dolores de cabeza. Siempre recuerda amigo developer, ya no estás en C#!!!! estás en Pandora... perdón en SSIS, y si quieres que tu integración funcione a la perfección, lo más importante es tener muy en cuenta tanto los tipos de dato y como el tamaño de los mismos.

Como siempre, cualquier inquietud, siéntanse libres de escribir sus comentarios.

Un abrazo

Piojo dev

Modelos, modelos... ojo con los modelos!!!!!

El día de hoy estaba terminando una implementación, para la interfaz de un proyecto en MVC. Consiste en un módulo que lee una tabla en una base de datos de una aplicación de integración y la idea es que esta tiene una configuración que se trabaja desde mi portal.

Tenía entonces un lindo ViewModel encargado de llevar la información de la vista al controlador... esa carreta la conocen verdad? en caso que la respuesta sea un no, visiten el siguiente link.

Bueno, todo iba de perlas hasta que tuve que hacer la parte POST del controlador. Al ejecutar el submit me aparecía el siguiente error:

me devané los sesos buscando la solución al problema y como en la mayoría de mis errores, era una cosa muy pequeña.

Supongamos que uds manejan un viewmodel para la comunicación que tiene un constructor de tipo:

public MyViewModel(MyObjectType myViewModel)
        {
            Property1 = myViewModel.Property1;
            Property2 = myViewModel.Property2;
            Property3 = myViewModel.Property3;
        }

Bien, en caso que ese sea su único constructor, MVC se enloquece buscando uno sin parámetros (aún no entiendo a ciencia cierta muy bien el por qué). Bueno la solución es super sencilla. Solo es necesario crear un constructor vacío (o por lo menos uno sin parámetros) de la siguiente manera:

public MyViewModel()
{
}

de este modo al tener el constructor vacío, todo funciona correctamente.

Dicen por ahí... "hasta ahí, normal."

Ahora, por qué me tomó tanto tiempo encontrar el error? Bien, un problema que sucede muy a menudo es cuando un ViewModel en nuestra aplicación tiene más ViewModel's uno dentro de otro, es decir un ViewModel anidado. Cuando estos modelos tienen cierta complejidad, la cosa se pone aún más difícl de detectar.

Bueno, si hubiese tenido en cuenta ese pequeño detalle en el ViewModel, seguramente no hubiese sido víctima de esa improductiva labor de encontrar el bug.

Así que tengan cuidado mis amigos... este tipo de situaciones nos conllevan mucho tiempo de solución y normalmente el problema es una bobada.

Como siempre, siéntanse en total libertad de comentar.

Un Abrazo

PiojoDev