Mejoras en DBLookup y en las fórmulas (versión 3.2.91y)
Hemos hecho varios cambios en el sistema de fórmulas, en particular en la funcionalidad 'DBLookup'. A continuación encontrarás un resumen de estos cambios y de cuándo se introdujeron.
Comprobación de fórmulas y mensajes de error mejorados
Hemos mejorado la gestión de errores para ofrecer mensajes de error mejores y más descriptivos. Ahora los mensajes de error incluyen la fórmula completa que falla. Así resulta mucho más fácil encontrar y corregir el problema.
También hemos añadido comprobaciones sobre el número de parámetros que se pasan a cada fórmula. Esto puede hacer que empieces a recibir errores en fórmulas que antes parecían funcionar. En realidad, la fórmula no habría funcionado, solo fallaba en silencio sin producir el resultado correcto. Ahora recibirás un mensaje de error si el número de parámetros no es correcto.
El uso de la función Message provocaba errores de transferencia con RapidiConnector versión 3.2.90a o posterior. Ya está corregido y la fórmula Message vuelve a funcionar correctamente.
También hemos corregido un problema con 'DBLookup' (que apareció hacia la versión 3.2.90a) que provocaba el bloqueo del RapidiConnector. Se debía a un error en la fórmula DBLookup (por ejemplo, cuando los argumentos del nombre de tabla o del nombre de campo eran incorrectos). Ahora estos errores se gestionan y se notifican correctamente. Al mismo tiempo hemos mejorado el momento de la notificación para comprobar y notificar estos errores de inmediato en lugar de seguir leyendo del sistema de origen - así recibirás el error lo antes posible.
Los cambios anteriores se introdujeron en la versión 3.2.91q
Las funciones CASE e IF también ofrecen ahora mejores mensajes de error cuando faltan argumentos. Este cambio se introdujo en la versión 3.2.91v.
DBLookup funciona ahora con cualquier Connection (no solo con 'SOURCEDS' o 'DESTDS')
El primer argumento de DBLookup es la Connection (o "DataSource", como se llamaba antes). Puedes indicar 'SOURCEDS' o 'DESTDS' - así DBLookup usa la Connection Source o Destination actual - o cualquier otra Connection que hayas configurado en Connections (como NAV001 o MSSQL001).
El problema era que, al usar una Connection distinta de SOURCEDS o DESTDS, DBLookup no reutilizaba correctamente la Connection, lo que provocaba el error "DataHandler already in use" si DBLookup se ejecutaba más de una vez - por ejemplo, si se leía más de un registro de la Source.
Este problema ya está corregido y puedes usar DBLookup con cualquier Connection, y con tantas Connections distintas como quieras.
Ejemplo de DBLookup: ##DBLookup('MSSQL002','Contact','CustomerNo',"No",'Name')
Usa 'SOURCEDS' o 'DESTDS' cuando sea posible
Aun así, debes seguir usando los sinónimos 'SOURCEDS' o 'DESTDS' para acceder a la Connection Source o Destination actual. De lo contrario, obtendrás el error "Connection already in use", ya que esas Connections ya las está usando el propio Transfer.
En definitiva, recomendamos encarecidamente usar 'SOURCEDS' con DBLookup, ya que normalmente rinde mucho mejor que otras Connections. Esto es especialmente cierto al leer datos a través del RapidiConnector.
Ejemplo de DBLookup con SOURCEDS: ##DBLookup('SOURCEDS','CONTACTPERSON','CUSTACCOUNT',"ACCOUNTNUM",'NAME')También hemos corregido un problema con DBLookup al usar 'DESTDS' junto con la Mirror Technology para leer de la Source. El Mirror indicaba entonces cada vez que todos los registros habían cambiado. Ya está corregido y el Mirror ignora ahora correctamente el DBLookup que usa 'DESTDS', como debe ser. Este error apareció hacia la versión 3.2.90a.
Los cambios anteriores se introdujeron en la versión 3.2.91y y necesitas esta versión o una posterior tanto en el Rapidi Central Service como en el o los RapidiConnector(s).
Por favor, contacta con nuestro equipo de soporte para programar una actualización.
Un saludo
Michael
