Ouch!
(and yes, that's what I meant by "no apparent reason" - found this TR value
idiosyncrasy after-the-fact, and was surprised by it at the time).
Mike White
Office: 813-978-2192
E-mail: [EMAIL PROTECTED]
"Thad Esser"
<[EMAIL PROTECTED] To: [email protected]
COM> cc:
Sent by: "Action Subject: Re: When is TR valid
Request System
discussion
list(ARSList)"
<[EMAIL PROTECTED]
ORG>
01/12/2007 16:59
Please respond to
arslist
**
LJ,
While all three of your bullets produce the same results, the first one is
the simplest. For me, the thing that put the final nail in the coffin on
the TR value was learning that if a field is used in a PushField, it will
have a TR value for that transaction, regardless if the value changed
(which is probably why Mike's filter was firing "for no apparent reason".
Of course, maybe his workflow is using Verizon math... lol).
>> '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.
This is the "Performance Considerations" argument. However, any trip to
the database should be inconsequential compared to the accuracy achieved by
not using the TR value. Think of how many filters you have that don't
involve a TR value - each of those are causing the same trip to the
database (all else being equal) that is alluded to above.
In the time it took me to respond, there were a couple of other posts
demonstrating how dicey it can be to use a TR value. Not using it avoids a
lot of headaches, and keeps the code easier to read. All in all, I haven't
seen where the extra complication is needed.
Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard
Bach
"L. J. Head" <[EMAIL PROTECTED]>
Sent by: "Action Request System discussion
list(ARSList)" <[email protected]> To
[EMAIL PROTECTED]
IST.ORG
01/12/2007 12:05 PM cc
Subject
Please respond to When is TR
[email protected] valid
**
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: [email protected]
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___
***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.***
__20060125_______________________This posting was submitted with HTML in
it___
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
