BLOG

¿Cuándo se disparan las actualizaciones?

Por [N4] jarboleya el | 6 Comments

La definición de actualización que encontramos en la ayuda dice:

“Una actualización es un subobjeto de tabla que permite actualizar el valor de los campos de un registro de una tabla enlazada cada vez que se produce un alta, una modificación o una baja en la tabla origen en la que definimos las actualizaciones.”

La cuestión que se plantea en este artículo es ¿Cuándo se ejecutan las actualizaciones en la tabla enlazada? Ya que cuando se declara una actualización no se ejecuta siempre que se produce un alta, baja o modificación en la tabla. La respuesta es que una actualización se ejecuta siempre que cambie alguno de los campos utilizados en las siguientes propiedades:

  • Caso A: Campo enlazado a la tabla en la que se produce la actualización.
  • Caso B: Campos utilizados en la condición del componente de actualización.
  • Caso C: Campos utilizados en la propiedad valor a actualizar.

Ejemplos

Ahora voy a poner un ejemplo de cada caso:

  • Ejemplo caso A. Si el campo enlazado donde se produce la actualización cambia de valor, entonces se lanza la actualización.
  • Ejemplo caso B: Si existe una condición que debe cumplirse para que se ejecute el componente de actualización, cualquier cambio de valor en alguno de los campos que intervengan en la fórmula producirá la evaluación de la condición y que se dispare la actualización.
  • Ejemplo caso C: Si en la fórmula del valor a actualizar, tanto por acumulación como por valor absoluto, se usan campos y alguno de ellos cambia de valor, el componente de actualización se dispara.

Como vemos hay una relación directa entre las variaciones de los valores de los campos que intervienen en estas tres propiedades. Por lo tanto, conociendo su funcionamiento podemos utilizar una astucia (recuerdos para Figueroa padrino de las astucias en Velneo) para forzar la ejecución de los componentes de actualización y usarlas en lugar de tener que crear tres eventos de tabla.

Supuesto

Supongamos que un campo de la tabla de artículos se calcula en base al valor que devuelve una función, lo que hace internamente esta función no tiene importancia en esta explicación. Supongamos que queremos que cada vez que se produce un alta, modificación o baja en la tabla histórica de referencias de un artículo se ejecute esta función y que se actualice el valor de un campo en la tabla de artículos. Podríamos plantear 3 posibles soluciones:

Soluciones

Solución A

  • Crear 3 eventos de tabla (interno o posterior a alta, baja y modificación).
  • En cada evento de tabla verificar si ha cambiado, por ejemplo, el campo referencia #REF. En caso afirmativo, se deberá cargar el registro del maestro para su modificación y ejecutar, por ejemplo, la función ART_ACT_REF(#ART) a la que le pasaremos el valor del campo artículo como parámetro. En caso de alta y baja se debería actualizar sobre el valor del campo artículo, sin embargo, en el caso de la baja habría que verificar si ha cambiado el artículo para lanzar el cálculo tanto para el artículo antigüo como para el nuevo, por lo que el código del evento de tabla se complica.

El handicap de esta solución es que hay que crear 3 eventos, además para no repetir código podría ser conveniente crear una función y lo más complicado es que en el evento de la modificación habría que controlar manualmente el cambio de artículo para deshacer con el viejo y rehacer con el nuevo.

 

Solución B

  • Crear una actualización a la tabla artículos desde la tabla referencias.
  • No ponemos nada en la condición para modificar del componente.
  • En la propiedad fórmula, llamamos a la función ART_ACT_REF_DSC(#ART, #REF), como vemos pasándole 2 parámetros. En realidad el parámetro #REF no se usa en la función, pero al estar presentes en la fórmula forzamos a que se evalúe y si cambia el valor de ese campo se fuerza la ejecución del componente de actualización.

El handicap de esta opción es que obliga a crear parámetros adicionales en la función cuando realmente no son necesarios.

 

 

Solución C (variación alternativa a la solución B)

  • Crear una actualización a la tabla artículos desde la tabla referencias.
  • En la condición para modificar del componente ponemos #REF=#REF. Como se puede observar la condición se cumple siempre por lo que no afecta a la ejecución de la actualización, la ventaja es que con esa fórmula estamos forzando que la actualización se ejecute si cambia la referencia del registro histórico del artículo.
  • En la propiedad fórmula, valor a ejecutar ejecutamos la función ART_ACT_REF_DSC(#ART) pasándole el artículo.

Esta es la opción que a priori deja el código de nuestra aplicación más sencillo de interpretar. Sería conveniente que en la propiedad comentario se podría especificar el motivo de incluir esa condición para modificar en el componente.

Con esta simple astucia nos ahorramos la creación de 3 eventos de tabla y el control manual del cambio del artículo lo que facilita en gran medida la programación además de convertirse en una alternativa de ejecución más óptima.

Velneo es el entorno ágil para el desarrollo
de aplicaciones empresariales

PRUEBA VELNEO

6 Responses to "¿Cuándo se disparan las actualizaciones?"
  1. [N4] spereira.pescapuerta dice:

    Se echa de menos alguna forma de Bloquear las actualizaciones, en V6 se podia hacer con variables globales en Memoria.
    No me vale con un campo, para hacer ciertos recalculos pues me interesa que no se lanzen las actualizaciones.

  2. Hola spereira,

    Puedes hacer lo que comentas sin necesidad de variables en memoria.

    Si, por ejemplo, quiero que no se dispare la actualización para un usuario determinado:

    1. Simplemente crea, por ejemplo, una variable global alfabética en disco con el identificador NO_ACT.
    2. Condiciona el componente de actualización con esta fórmula indexOfString($NO_ACT@ProyectoDatos.dat, sysUserName, 0, 0)

    Si el nombre del usuario lo metes en la variable global no se ejecutará esa actualización si el alta, baja o modificación la realiza ese usuario.
    Si el nombre del usuario no aparece en la variable global sí se ejecutará la actualización.

    Si quieres condicionar por otros factores, simplemente cambia la condición del componente de actualización. Recuerda que en la condición de un componente de actualización puedes ejecutar una función que puede resolver la complejidad que necesites.

    Un saludo.

  3. [N1] juan_figueroa.telefonica dice:

    Gracias por el recuerdo de los tiempos de las astucias v. trucos. Recuerdo que le gané al mismísimo Mario Conde (un fortísimo competidor, por cierto) un concurso de iconos para la sección de astucias de tu web: una V++, que aun anda por alguna web.

    Ahora, ciñéndonos al tema, ¿Hay alguna diferencia con las actualizaciones de la 6.X ?

  4. Hola Juan,

    Qué alegría verte de nuevo activo por el foro y el blog.

    Sí señor, le ganaste el concurso al amigo Mario, que ya estaba dando guerra en aquellos tiempos 🙂
    Recuerdo perfectamente el logo V++ que tengo guardado en algún CD.

    Respecto a tu pregunta comentarte que funcionalmente no hay diferencias. Las actualizaciones se ejecutan en el mismo orden, con las mismas características de valor absoluto o acumulación, con condición de ejecución para cada componente. Vamos, que si sabías programar actualizaciones en 6.x sabes programar actualizaciones en V7.

    A ver si nos vemos en Life is soft.

    Un saludo.

  5. [N1] juan_figueroa.telefonica dice:

    Buenos recuerdos, Jesús.

    Anoto que no hay diferencias con V 6.x.

    Pero, un ruego, ¿sería pedir mucho, que, tanto en el manual y en la documentación, como en artículos de este Blog se advirtiera, ya al principio, que no o sí hay diferencias con V6.x?
    Así, aunque siempre es bueno un repaso, podríamos evitarnos los que conocemos la versión 6.x, su lectura en profundidad.
    Podría tener cada tema una indicación de p. e. como alguna de estas:

    – No existen diferencias con V6.x
    – Existen ligeras diferencias con V6.x
    – Existen diferencias profundas con V6.x
    – Nuevo objeto o funcionalidad no existente en V6.x

    Nos veremos el viernes en “Life is soft”

  6. [N1] zenonburgos dice:

    Hola Jesús, espero puedas ayudarme en este pequeño hoyo en el que estoy. Siguiendo los ejemplos de tu video de pedidos, he estado experimentando con diferentes datos. Resulta que por malos procedimientos me han quedado datos remanentes que las actualizaciones no me corrigen: el acumulado en artículos (en lo cual borré los artículos y pedidos y los volví a ingresar, ahora todo bien), he dejado varios clientes que también tienen el dato acumulado erróneo, mi pregunta, como corrijo el acumulado de pedidos en los clientes?

Deja un comentario

Esta web utiliza cookies. Si continúa navegando acepta dichas cookies y nuestra política de cookies. Gracias. ACEPTAR

Aviso de cookies