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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
