Hello,
Try to:
- Disable your events.
- Create one more logical unit with a history of that field.
- Create an event that will update the field with the oldest value each time a new LU is inserted.
I hope this will be more stable.
Best regards
Bart
Hi,
thanks for your response, but I don't know if I'm understanding this right, but it seems like it's not gonna solve anything and I'm gonna get the noose again.
If I understand correctly, I'll create a modify event on the first field, where I'll create a new record in the newly created LU. I will do the same for the second field.
And over the newly created LU I will create an event when a new record is added to the LU. And that will ensure that I synchronize the two fields.
But this seems like a pure loop to me, because once the event over the new LU triggers a modify over a field, it will automatically write itself. The only possibility I can think of is that the event on the new LU wouldn't use the modify function, but would directly use the SQL update event and it wouldn't run the modify event on those fields.
If I misunderstood that, I apologize. And thanks again for the reply.
Hello,
You have a good understanding of the issue, but let's refine the solution by adding another check to ensure we have the newest value in the new LU. The condition for the first event (on LU1) should be:
`&NEW:CF_C_POPIS_WF != &OLD:CF_C_POPIS_WF AND &NEW:CF_C_POPIS_WF != NEW_LU.VALUE AND &NEW:CF_C_POPIS_WF != LU2.CF_C_POPIS_WF`
Similarly, an analogous condition should be added for the second event on LU2 to ensure that the value does not loop back:
`&NEW:CF_C_POPIS_WF != &OLD:CF_C_POPIS_WF AND &NEW:CF_C_POPIS_WF != NEW_LU.VALUE AND &NEW:CF_C_POPIS_WF != LU1.CF_C_POPIS_WF`
The conditions as formulated help prevent looping by adding checks that ensure a field's new value is not only different from its previous value but also distinct from the corresponding values in other logical unit. Specifically, each condition checks three things:
1. The value must change (`&NEW:CF_C_POPIS_WF != &OLD:CF_C_POPIS_WF`), which avoids unnecessary triggers if the value hasn't actually been updated.
2. The new value must be different from the value in the new LU (`&NEW:CF_C_POPIS_WF != NEW_LU.VALUE`), helping to maintain consistency across different logical units without redundant updates.
3. The new value must not match the corresponding value in the other logical unit (`&NEW:CF_C_POPIS_WF != LU2.CF_C_POPIS_WF` for the first event and vice versa for the second event), which is critical for ensuring that changes in one logical unit do not cause unnecessary updates in another due to feedback loops.
These checks should effectively prevent the looping issue by making sure that the events are only triggered by genuine changes that need to be synchronized across the units, not by the mere act of copying values back and forth.