Apex Code Development You need to sign in to do that
Don't have an account?
ndgani Did field change via trigger or manually
Hello all
my situation is:
i have two account record types:
parent
child
certain fields exist and are relevant for both record types.
these fields should be synchronized between parent and child.
so far so good.
the problem starts here:
if one of these fields was updated (manually - not via trigger) in the child,
i should not sync that field from the parent ever again.
how can i know if such an event occured (manual change) ?
thanks
ndgani
If you have both parent and child stored in the same object then the same trigger will execute when both the parent and child are updated and if you are updating children when a parent is modified then you are calling update on the same object type (account) as is being updated already, thus recursion. Perhaps not recursion in the sense that the same record is being updated but in the sense that the same trigger is executed twice.
That doesn't seem to be the issue you are concerned about here but it may still be something for you to evaluate if you ever call update on the same object within an update trigger as it appears you might be.
For what you've described, it seems like you need another field on the child that indicates whether it is to be slaved off the parent or not - a field you have to flip when the user modifies it, i.e. when the child is in the original trigger collection (and not the recursive firing via an update from a parent change).
Either way, if you are calling update for the same object type in an update trigger you are most likely going to wind up using static variables to communicate that the nth pass is not the first and perhaps what records are to be ignored.
All Answers
tnx for the replies.
I dont really see how this is related to trigger recursion, so maybe i should explain myself better.
there is a trigger on the parent update event, that checks if any of the relevant fields have been
changed. if a relevant field was changed, copy it to the same field in the child.
if one of the relevant fields was changed in the child (by a user - not by the parent update trigger)
then it should not be changed on the next execution of the parent's update trigger.
if a field was never changed by a user, the parent's update trigger should continue to copy that field to the
child at every execution.
If you have both parent and child stored in the same object then the same trigger will execute when both the parent and child are updated and if you are updating children when a parent is modified then you are calling update on the same object type (account) as is being updated already, thus recursion. Perhaps not recursion in the sense that the same record is being updated but in the sense that the same trigger is executed twice.
That doesn't seem to be the issue you are concerned about here but it may still be something for you to evaluate if you ever call update on the same object within an update trigger as it appears you might be.
For what you've described, it seems like you need another field on the child that indicates whether it is to be slaved off the parent or not - a field you have to flip when the user modifies it, i.e. when the child is in the original trigger collection (and not the recursive firing via an update from a parent change).
Either way, if you are calling update for the same object type in an update trigger you are most likely going to wind up using static variables to communicate that the nth pass is not the first and perhaps what records are to be ignored.
thanks mtbclimber
you are right about the recursion, and your solution of a static field
is my current course of action and seems to be the best solution.
thank you for your help
ndgani