"Only new or changed field values are part of a transaction."
Well, not exactly. 'Found it some time ago when Filters whose Run If
included 'TR.fieldname' != $NULL$ fired for no apparent reason. If another
Filter updates a field with its then-current value, the TR value of the
target field is not treated as null. ARS treats it as a change (sometimes?
If I remember correctly, it's intermittent).
To circumvent, we use or include 'TR.fieldname' != 'DB.fieldname.'
In your example, I'd code 'TR.Status' = "Fixed" AND 'TR.Status' !=
'DB.Status'
Mike White
Office: 813-978-2192
E-mail: [EMAIL PROTECTED]
"L. J. Head"
<[EMAIL PROTECTED] To: arslist@ARSLIST.ORG
M> cc:
Sent by: "Action Subject: When is TR valid
Request System
discussion
list(ARSList)"
<[EMAIL PROTECTED]
ORG>
01/12/2007 15:05
Please respond to
arslist
**
Ok...I'm starting another thread because I don't want to muck with the
other one...
First...some excerpts from the manuals
Basic - p486
* 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.
Now...I typically see TR used in a 'is a value changing to this and wasn't
previously this'...I have seen this several ways
'Status' = "Fixed" AND 'DB.Status' != "Fixed"
OR
'TR.Status' = "Fixed" AND 'DB.Status' != "Fixed"
OR
'TR.Status' = "Fixed" AND 'DB.Status' != "Fixed" AND 'TR.Status' != $NULL$
but according to this excerpt...one can assume that TR fires only on the
Transaction and therefore if you want a filter to fire every time the
status changes to "Fixed" then you would use
'TR.Status' = "Fixed"
I hear the argument of 'what if it was already fixed...I don't want to fire
then'
then the second example above would be the appropriate qualification
'TR.Status' = "Fixed" AND 'DB.Status' != "Fixed"
'then I hear 'but I get the same results with'
'Status' = "Fixed" AND 'DB.Status' != "Fixed"
Yes...you do but I believe the difference between the two qualifications is
the very important 3rd bullet. "check the value for the transaction first
and then check the database if a new value is not found in the
transaction". If no transaction value exists...you don't care what the DB
value is if your looking for when the value changes...so I think it removes
the 'else' statement from the usage without the TR.
If I am understanding any of this incorrectly please correct me...but I
think that there is a valid reason for the TR capability...if it is
properly understood by the developer.
p.s.
Before re-reading the manual on the finer points about this...I also
assumed it was useless...:)
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Thad Esser
Sent: Friday, January 12, 2007 11:58 AM
To: arslist@ARSLIST.ORG
Subject: Re: How to not include weekends in query?
**
Dwayne,
In step 2, why use "TR.Set hours open" instead of just "Set hours Open" in
the filter condition?
<peeve>
I'm still waiting/trying to find a situation where the TR value is required
and 100% accurate (however, I have no issue with using DB when needed). So
far, in everything I've come up with or seen, it is either not necessary or
not 100% accurate. Given the confusion that usually surrounds it, I would
prefer to see it gone. Basically, If you think you need the TR value, you
are probably over complicating your situation, or not getting perfect
results. Naturally, I am willing to be proved wrong on this. :-)
</peeve>
Regards,
Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard
Bach
__20060125_______________________This posting was submitted with HTML in
it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
