I think the answer to that is that the field is being set...the push doesn't check to see if the value was previously the value you are changing....thus there is a transaction value...thus TR contains a value
_____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David Sent: Friday, January 12, 2007 8:13 PM To: [email protected] Subject: Re: When is TR valid I use TR.field all the time. As noted earlier you need to think about the meaning. TR.field will contain the current value of the field if the value in the field changes. Since Status is a required field it will always contain a value and TR.Status != $NULL$ will only execute if the Status field changes. 'TR.Status' = "Fixed" should only be true the first time the Status field changes to Fixed. After that 'TR.Status' = 'Fixed' should only fire if the Status field changes to a different value and then back to Fixed. Now that I've said that I did a quick test. A push fields action always causes the TR.Status = "Fixed" to fire even if the value was set to Fixed in earlier workflow.. That defeats the purpose of using TR.field functionality that I thought was working so well. Has anyone asked Support why it functions differently between a simple change in the field and with a push fields action? ------Original Message------ From: Thad Esser To: Arslist ReplyTo: Arslist Sent: Jan 12, 2007 4:59 PM Subject: Re: When is TR valid ** 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]> 01/12/2007 12:05 PM Please respond to [email protected] To [email protected] cc Subject When is TR 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___ Dave -------------------------- [EMAIL PROTECTED] (Wireless) _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
