Dave, 

Misi is correct in saying that this statement is wrong:  "Only new or 
changed field values are part of a transaction." 

TR values do NOT detect change.  The only reliable way to detect change is 
to compare the current value with what is stored in the database,  i.e. 
('Field' != 'DB.Field'). 

Sorry guys, but this is the one ARS topic that makes me rabid. 

Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard 
Bach



"Misi Mladoniczky" <[EMAIL PROTECTED]> 
Sent by: "Action Request System discussion list(ARSList)" 
<arslist@ARSLIST.ORG>
10/04/2007 01:36 PM
Please respond to
arslist@ARSLIST.ORG


To
arslist@ARSLIST.ORG
cc

Subject
Re: Filter Problem






Hi Dave,

The problem here is that a TR value van be NULL, but is still part of the
transaction.

All fields not part of the transaction will also have a TR value of NULL.

The statement "Only new or changed field values are part of a
transaction." is wrong.

TR-values can be set in a number of other ways, where the TR value and DB
value are the same:
- Modify-All
- Push-Fields
- Set-fields-filter that sets a field to the same value as in the DB
- Other API-programs

These two ways of checking for a change has the same effect, but I prefer
the first one:
('Field'    != 'DB.Field' AND 'Field'    != $NULL$)
('TR.Field' != 'DB.Field' AND 'TR.Field' != $NULL$)

If you want to track a change that includes a change to NULL, there is
only one (simple) way of doing it:
('Field' !=  'DB.Field)

        Best Regards - Misi, RRR AB, http://www.rrr.se

Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.

> Esser,
>
> TR indeed have some usefulness. Following is taken straight from page 36
> of
> "Work-Flow Objects-700.pdf" We have a few filters that need to fire ONLY
> if
> that particular value is changed in a given transaction and it fires as
> intended and doesn't fire when it shouldn't. It works fine for me.
>
>
> For filters, you can specify whether the qualification is to reference
> field
> values in the transaction only, in the database only, or in both:
>  To check the value for the transaction only, enter the field name as
> 'TR.<field>' (for example, 'TR.Submitter').
>  To check the value in the database only, enter the field name as
> 'DB.<field>'
> (for example, 'DB.Submitter').
>  To check the value for the transaction first and then check the 
database
> if
> a new value is not found in the transaction, enter the field name with 
no
> prefix.
> Only new or changed field values are part of a transaction.
> The TR and DB prefixes work only in filter Run If qualifications.
>
> If we do 'Field' != DB.Field and if the value is not changed in a
> transaction, it'll always be false (according to the guidelines from BMC
> above) and we should be usingTR.Field != $NULL$, shouldn't we?? At least
> that was my understanding and I'm still new to ARS.
>
> Thank you,
>
> Dave.
>
>
> Thad K Esser wrote:
>>
>>>> My two rules for TR and DB values:
>>>>         1.  Don't use TR values (DB values are
>>>> useful & good).
>>>>         2.  If you need to use a TR value, see rule
>>>> #1.
>>>>
>>>> Thad Esser
>>>> Remedy Developer
>>>> "Argue for your limitations, and sure enough,
>>>> they're yours."-- Richard
>>>> Bach


***IMPORTANT NOTICE: This communication, including any attachment, contains 
information that may be confidential or privileged, and is intended solely for 
the entity or individual to whom it is addressed.  If you are not the intended 
recipient, you should delete this message and are hereby notified that any 
disclosure, copying, or distribution of this message is strictly prohibited.  
Nothing in this email, including any attachment, is intended to be a legally 
binding signature.***

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the 
Answers Are"

Reply via email to