Hi,
The string you suggested tracks ALL changes, regardless of API or client:
'field' != 'DB.field'
If you want to skip the situation where a field is set to NULL, just do:
'field' != 'DB.field' AND 'field' != $NULL$
My recommendation is actually to NEVER use the 'TR.field' value, except in
very rare circumstances. And definitely not if you are looking for changes
to a field. 'TR.field' has NOTHING to do with changes.
Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011)
Products from RRR Scandinavia (3 x Best R.O.I. Award at WWRUG10/11/12):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Hi,
> I have gone through various discussions on 'field' != 'DB.field' on the
> forum here but still little confused.
> Currently, we have a code 'field' != 'DB.field' and looks like it tracks
> all changes to the field.
> It is even tracking null value change as well.
> For Example, I am updating Audit log something like "value changed from A
> to B".
> But I do see entries of "value changed from to "
>
> Would this Run If qual in filter also tracks when a null is pushed to this
> field from API.
> My understanding is when a null is pushed, field has a transaction value
> of
> null but which is = to DB.field, then why is this filter firing?
> Did anyone encounter such a case?
> As I would like to stop logging "value changed from to " in the audit,
> as
> it is of no use.
> Pl advise.
> Thanks,
> Raj
>
> _______________________________________________________________________________
> 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"
