Es la característica estrella de las tablas Velneo. Poder actualizar valores en tablas maestras desde sus plurales sin programar código es muy atractivo, sin duda, pero todavía lo es más la rapidez de los cálculos que al estar automatizados en el propio sistema Velneo son más rápidos que si los programamos nosotros en procesos o funciones y además la fiabilidad de que funcionan bien en todos los casos, aunque en la definición solo le digamos lo que tienen que hacer en el alta.
Dadas sus virtudes no hay duda, siempre que puedas hacer una actualización no escribas código en los eventos de tabla. Es más, deberías pensarlo al revés, siempre que vayas a escribir código en un evento de tabla piensa si puedes hacerlo mediante una actualización.
Hay que tener en cuenta que a la facilidad de configuración de una actualización se le une la posibilidad de condicionarla lo que facilita la realización de cálculos más complejos. Aplicando estos criterios, en muchos casos es preferible hacer actualizaciones en tablas maestras acumulando líneas totales, líneas servidas, etc. que nos permiten declarar en la tabla maestra un campo que nos indique si ya está servido o no en base a los valores de los campos acumulados en vez de escribir código en ningún evento de tabla.
Es habitual usar actualizaciones para almacenar en una tabla maestra los últimos valores, por ejemplo en el cliente podríamos guardar la fecha del último pedido. En estos casos tanto en alta como en modificación no hay problema a la hora de condicionar la actualización y dejar el valor correcto en el maestro, sin embargo cuando damos la baja de un pedido que era el último de un cliente nos encontraremos de que no podemos actualizar la fecha del último pedido, salvo que tengamos un puntero a hermano contiguo o un singular de plural que nos facilite obtener dicho dato. Este caso debemos tenerlo en cuenta para en el trigger posterior a la baja ejecutar un código que se encargue de buscar el último pedido del cliente y actualizar su fecha.
Si tenemos que actualizar más de un campo en la tabla maestra no tiene ningún sentido crear una actualización para cada campo. Esto además de hacer crecer el tamaño de nuestro proyecto es peor a nivel de rendimiento porque obliga a ejecutar varias actualizaciones contra el mismo registro. Por lo tanto siempre que tengamos que hacer actualizaciones a una tabla maestra debemos incluir en la misma tantos componentes de actualización como sean necesarios.
La versatilidad de las actualizaciones se ve potenciada con la posibilidad de utilizar condiciones. El principal motivo es que Velneo es capaz de actualizar en función de la condición de forma automática, es decir, que si se cumple la condición aplica la actualización y si deja de cumplirse aplica la actualización contraria, y lo más importante sin programar lo que reduce la posibilidad de errores del programador.
Por ejemplo si condicionamos una actualización del nº de líneas recibidas de un pedido a que la línea esté recibida o cancelada, cuando se cumple la condición se suma 1 al campo de la tabla maestra, sin embargo, al cambiar la condición si ya no se cumple se resta 1.
Por este motivo es conveniente pensar si podemos crear una actualización antes de escribir código.
Con las grandes virtudes que tienen las actualizaciones es lógico usarlas masivamente y con total tranquilidad.
Sin embargo, de la misma forma que nos puede ocurrir con los contenidos iniciales de campos donde podemos por mala definición crear un cálculo recursivo, en las actualizaciones nos puede pasar lo mismo. Por ejemplo, podríamos cometer el error de que la tabla A actualiza la tabla B, la tabla B actualiza la tabla C y la tabla C actualiza la tabla A produciendo un error por recursividad ya que tras la modificación de la tabla C a la A volvería a empezar el ciclo. Sin duda se trataría de un error de programación que seguramente podemos evitar aplicando condiciones a las actualizaciones para evitar que ejecute más de un ciclo.
