You might double check you're doing an after trigger. For before triggers, the trigger context has the new values for the trigger object loaded, but nothing has been committed yet, so any calls to the database will return the old values for both formula fields and regular fields. In after triggers this is not the case.
Imagine the following trigger
trigger Example on Account (before update, after update) {
system.debug('==>trigger.new[0].name: ' + trigger.new[0].name);
system.debug('==>trigger.old[0].name: ' + trigger.old[0].name);
system.debug('==>queried: ' +
[select name from Account where id = :trigger.new[0].id][0].name);
}
Then imaging the following code
Account account = new Account(name = 'Hello');
insert account;
account.name = 'World';
update account;
For the update you'd expect the following output
/* Before Trigger */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: Hello
/* After Trigger */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World
Things can get stranger if you something causes a second round of trigger execution, such as a field update. The values are what you'd expect for the first round, but the second round you'd expect trigger.old[0].name to match the queried value in the before trigger, but that's not actually the case.
/* Before Trigger - Pre Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: Hello
/* After Trigger - Pre Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World
/* Before Trigger - Post Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World
/* After Trigger - Post Workflow */
==>trigger.new[0].name: World
==>trigger.old[0].name: Hello
==>queried: World
Calling recBasinCalc
The first thing I notice is that recBasinCalc
is defined with two parameters but your trigger is calling it with only one. You might be able to get away with just one parameter, depending on your full class definition.
On the value comparison:
Yes, that should work. Keep in mind that when using ==
on primitives Apex does a value comparison but for reference-types it checks the memory location instead (so if you implement a custom class you may want to provide your own equals() method.)
Best Answer
I am not sure if you could use the field set directly to compare but you can use the sObject's
get
method to do the job