James,
TR.Field - "Transactional" value. Its the value that will be used in the
"UPDATE" sql statement that gets sent to the database.
DB.Field - "Database" value. It's the value that is currently in the
database.
Field - Without TR or DB, the value used is the "most current" value for
the field.
In my passionate opinion :-) TR has no value and should never be used;
however, the DB value is useful.
The DB value is useful to detect if a field value is different from what is
in the database. The Run If would be ('Field' != 'DB.Field'). That
qualification will always work to detect a difference.
The TR value is often suggested as a way to detect if a field has changed,
as in ('TR.Field' != 'DB.Field'). The issue with this is that if the field
isn't part of the update, the TR value will be null, so then you have to
test for that, as in ('TR.Field' != 'DB.Field' AND 'TR.Field' != $ NULL$).
But sometimes the field is being cleared out, the field is legitimately
changing to null, so in that case the TR value is null because that's the
new value, not because it didn't change. So then you need to account for
that. It gets messier and messier.
Sometimes this is suggested: ('TR.Field' != $ NULL$ ) It has all the same
issues detecting for null, plus this... During a push field action, all
the fields listed will be part of the UPDATE statement (meaning they will
have a TR value), regardless of whether or not the values are changing. So
your filter will fire even though the value didn't change. Maybe that's a
problem, maybe its not. Either way your code isn't doing what was intended.
So using a TR value is confusing at best, and sometimes outright wrong,
when a simple ('Field' != 'DB.Field') always does the trick.
As far as your question about (TR.Field=DB.Field), most likely that will
not give you the results you want, but you hadn't stated what you have in
mind by "correct" so I couldn't say for sure. (for your clause to come out
as true, the two values would have to be equal. That would only be the
case in the push fields situation above.)
Hopefully that clarifies things.
Thad
On Thu, May 8, 2014 at 8:21 AM, James Smith <bmcremedyarslis...@gmail.com>wrote:
> Hi List,
>
> We can achieve things without using TR and DB values in a filter by just
> using Field but I do not understand why they have been developed to use? I
> have heard from many remedy developers like Misi and BMC who suggest not to
> use TR and DB in Run If qualification of a filter but why?
>
> Why it is not recommended to use TR and DB values?
>
> What if I use TR.Field=DB.Field? Will it yield a correct result? In BMC
> documentation also they have not given any example where they used TR and
> DB together in a qualification.
>
> Appreciate your thoughts!
>
> Cheers,
> James
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
