+ Start a Discussion
ndganindgani 

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 

Best Answer chosen by Admin (Salesforce Developers) 
mtbclimbermtbclimber

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

mtbclimbermtbclimber
Not sure I understand the entirety of your use case but it seems like a recursion issue potentially. If so check out the static variables section ("Using static methods and variables" ) to controlling trigger recursion in the Apex Developer Guide
Message Edited by mtbclimber on 02-15-2010 09:46 AM
ryanhcaryanhca
The Apex Cookbook also has a code sample for controlling recursion in triggers.
ndganindgani

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.

 

 

mtbclimbermtbclimber

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.

This was selected as the best answer
ndganindgani

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