Hermano contiguo y actualización en cascada?


([N1] imesis.prodigy) #1

Hola.

Según la lógica de los hermanos contiguos, sería posible realizar una actualización en cascada con tan sólo modificar un campo.

Para ello tendríamos:

Campo: REG_ANT, hermano contiguo anterior

Campo: SALDO_INICIAL, cuyo contenido inicial = REG_ANT.SALDO_INICIAL+REG_ANT.CARGO-REG_ANT.ABONO

Entonces, si en una lista de 100 registros se modifica el número 8 en el campo SALDO_INICIAL, CARGO o ABONO, esto debería causar la modificación automática de su siguiente registro, ya que estos campos se contienen en la fórmula del contenido inicial del SALDO_INICIAL. Luego, como se modifica el registro 9, también se deberá modificar el 10, 11, 12, …, 100

Pregunta:

¿Ha resuelto Velneo el manejo completo de los campos tipo hermano contiguo y sus implicaciones?

Y de ser así, ¿funciona esta lógica de actualización en cascada?

Porque he realizado pruebas y no se actualizan los registros hacia abajo y antes de seguir indagando si estoy haciendo algo mal, me gustaría saber si Velneo así lo tiene contemplado.

Gracias por su ayuda.

Saludos.

José Pablo


([N1] cristianvg2003) #2

Hola, Si tu lógica tiene sentido solo en parte:

Aunque esten enlazados mediante el campo hermano contiguo el registro hermano no es “consciente” de los cambios de su hermano anterior, ahora SI ESTUVIERAN OPERATIVAS las actualizaciones a hermano o modifcar registro maestro (y usando el hermano como un maestro como en v6) podrías usar tu lógica, desgraciadamente estas actualizaciones no están disponibles en al v7.

otro aparte es que aunque lo estuvieran no se si sea sano confiar esas modificaciones a los cambios en los registros o las actualizaciones por lo que en listas muy muy largas se generaría algo asi como un bucle “infinito” de actualizaciones en cascada.

 

Mi solución, realmente fue muy simple: escribí los triggers posterior al alta, baja y modificación que buscan los registros que deben estar afectados y les modifican su VALOR_INI de acuerdo a la lógica necesaria, el resultado termino siendo un código mas simple y sin el riesgo de alguna subida de memoria por una cantidad muy grande de eventos en cascada.

 

un saludo,


([N1] imesis.prodigy) #3

Agradezco tu sugerencia, Cristianvq.

Aún al hacerlo por trigger, se presenta la actualización en cascada, no es así?

Hablo en este caso de la modificación del campo VALOR_INI.

Me imagino cargar la lista de los registros siguientes al modificado y realizar un “recorrer lista lectura/escritura”. Por cada registro modificado se va a lanzar el trigger “anterior a una modificación”.

¿Alguna sugerencia de como debo cargar la lista de los siguientes? No debe ser por código mayor al modificado, ya que puede haber un registro posterior pero con fecha anterior.

Podría cargar la lista y filtrar para fecha mayor a la del registro modificado. Pero en tal caso, ¿cómo evitar que se de la modificación en cascada?

Nuevamente gracias.

Saludos.


([N1] cristianvg2003) #4

Exacto es tal cual describes en mi caso tengo una variable global que me sirve de flag para evitar que se ejecute el código “posterior a modificación” del resto de fichas que voy a actualizar y listo apenas termino de actualizar vuelvo la variable al estado de permitir actualizaciones y va de lujo, muy eficiente y limpio

 

 

un saludo


([N1] imesis.prodigy) #5

Perfecto, es así como lo voy a implementar.

Dónde me aconsejas declarar la variable global? (proyecto de datos o en la tabla)

Nuevamente muchas gracias por tu ayuda.

Saludos.


([N4] innovadb) #6

Tal como lo planteáis funcionará bien para algunas cosas, pero no para otras, por ejemplo el recalculo de existencias sobre la tabla de movimientos.

En este sistema si dos personas modifican distintos registros, es posible que uno de ellos no haga el recalculo, por que el otro lo tiene desactivado por la variable.

Una posible solución es condicionar el trigger a si ha cambiado un campo en la ficha, por ejemplo, en una tabla de movimientos comprobar si cambió el campo cantidad o importe disparamos el trigger, pero como el trigger solo modifica las existencias y precio medio no se va a disparar en las siguientes lineas.

Este sistema tampoco es perfecto, ya que se puede dar un bloqueo y deshacer la transacción, pero es mas fiable que el que planteais.

Un saludo