BC y nulos

Como parte de un trabajo de migracion de datos a partir de una planilla excel en la que podrian no venir todos los datos de la manera esperada, me propuse realizar la importacion  de las filas via BC.

Para ello todos los atributos de la transaccion afectada (menos la PK) fueron seteadas con nullable = yes.

Luego en el proceso una vez obtenido el emparejamiento de los atributos y las columnas del tipo Att = col, almacenados en un SDT para el proposito, realice la importacion con los siguientes pasos:

1. &Xml = &Transaction1.toXml() // &xml (longvarchar) y &Transaction1 (BC)
2. Por cada atributo que exista en el par Atributo, Columna
• &Buscar = '<'+&Atributo+'/>' // buscamos el atributo vacio (los numericos tienen otro tratamiento)
• &Reemplazar = '<'+&Atributo+'>'+&Dato+'</'+&Atributo+'>'
• &Xml = &Xml.Replace(&Buscar,&Reemplazar)
3. &Transaction1.FromXml(&Xml)
4. &Transaction1.Save()
5. Commit

Ahora bien, el problema se daba con las claves extranjeras que no estaban referenciadas, provocaba violacion de la integridad referencial.

A pesar de haber modificado las propiedades Empty As Null en la transaccion para cada atributo, me seguia rebotando.

Finalmente encontre una documentacion que hablaba que esa propiedad no funcionaba para BC por lo que habria que poner una regla del tipo ClaveExt.SetNull() if ClaveExt.isEmpty(); en la transaccion referenciada por el BC.

Con eso solucionamos el problema y pudimos migrar los datos correctamente (los que pudimos, el resto quedo en null).

En otra entrada voy a dar mas detalles de la solucion completa y presentar el asistente que creamos para la migracion que bien puede ser objeto de  un pattern que proximamente estaremos encarando.

Un bug viejo, descubierto recien ahora

Hace poco me encontre con un problema dificil de explicar al cliente. Una Kb que habia desarrollado desde cero en la version 9.0 hace casi dos años luego paso a la version X y ultimamente en la Ev1, demoraba mucho mas de lo aceptable en cada especificacion y generacion.

Si bien los objetos en los que demoraba tampoco eran comunes, unas transacciones con muchas subordinaciones (en algunos casos hasta 19, y hasta 3 niveles) y muchas formulas (varios sum verticales sobre las subordinadas y varias horizontales sobre estas sum). Algunas de estas transacciones llevaban mas de 20 minutos solo de especificacion. En toda la KB habia mas de 20 de estas transacciones (10 con interface y 10 BC), lo que nos llevaba mas de 9 horas para un build all o un build normal ya que siempre que se tocaba alguna de estas transacciones las especificaba todas.

Despues de muchas dudas y bajo mucha presion decidi comentar el problema en el foro de Artech y confieso sin muchas esperanzas de que alguien aporte algo.

Mi sopresa fue que la misma gente de Artech se intereso en el problema y siguiendo por fuera del foro acompañaron la solucion (que vino por corregir el especificador y facilitarnos un build que arreglaba el problema).

Ahora me arrepiento de no haber informado antes del problema.