Given that there is confusion about this topic, I wanted to weigh in on the topic and be very clear and very explicit about that is happening.
First, some definitions: Say you have a field named A, what are the various interpretations TR.A -- Get the current transaction value of the field A. This is what is passed into the server on the API and anything assigned to it or changed on it in filter workflow. NOTE: This value could be NULL because either a) an explicit NULL was assigned to the value b) no value was passed to the server for this field And, no, you cannot tell the difference by just looking at TR.A. The server can (see the action under just A below) but you cannot. DB.A -- Get the database value of field A. This is the value the field had PREVIOUS to this transaction. If this is a Create operation, DB.A is always NULL. If a Set or Delete or Get operation, it is the value in the DB before the call started. If a Merge, it acts like a Create if there was no entry or a Set if there was an entry that you are merging into. A -- Get the CURRENT VALUE of the field A. This is the TR value if there is one or the DB value if there is no value for A. VERY IMPORTANT to note is that if A has been ASSIGNED a value of NULL, it has a value assigned and that will be used. However if the transaction value of A is NULL because it has not been passed or assigned a value, then it reads through to the DB. NOTE: A very important distinction is that TR.A and A ARE NOT THE SAME VALUE. If the client did not pass the value of A to the server and there is no workflow that assigns a value to A, the value of TR.A will be NULL although the value of A may not be null because there is a value in the DB. It is also important to note that the BMC supplied clients -- Windows and Web -- they know when a field value is changed in a particular transaction and they DO NOT send value for fields who have not changed value. This is done for efficiency to minimize traffic on the network sending data that is not changed. So, TR.A can indeed be NULL (TR.A part b above) when field A has a value. Now, with that all said..... cpgold is almost correct. 'A' != 'DB.A' is all the testing you need to see if the value has changed. With this one test, you will trigger if the value is DIFFERENT in the transaction and the database. NOTE: that this is at the time that this filter fires. If you have filters AFTER this filter that change the value of A, then all bets are off. But, that should be obvious. What is incorrect in the note is that this is equivalent to 'TR.A' != 'DB.A' and 'TR.A' != $NULL$ Why, because this qualification can have false returns because of the confusion between ASSIGNED TO NULL vs. not assigned a value. For example, if you had a situation where you were changing the value of A from xxx to NULL (in other words you were explicitly clearing the value), you would get two different results. 'A' != 'DB.A' would evaluate to TRUE 'TR.A' != 'DB.A' and 'TR.A' != $NULL$ would evaluate to FALSE Why? Because TR.A does not equal DB.A so that is TRUE but TR.A is NULL because it is assigning it to NULL so TR.A not equal to NULL would evaluate to FALSE so TRUE and FALSE is FALSE So, these two qualifications are not identical. They actually are slightly -- and importantly -- different. So, they are not redundant, but the second qualification actually causes you to not run when you are clearing the field explicitly when you should be running because the value is changing. The simpler qualification of 'A' != 'DB.A' covers all situations and permutations regardless of the client or how it is working or an API program or anything. I hope this helps clarify what the three different values are and what the difference between them is and the subtle issue about NULL really having two different meanings (not defending, merely explaining) in the TR. case that sometimes can cause confusion. I hope this has helped clarify things for everyone. Doug Mueller ________________________________ From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of cpgold Sent: Thursday, April 15, 2010 3:27 PM To: [email protected] Subject: Re: TR vs DB sanity check please ** NOTE Listers: 'AssignedToTech' != 'DB.AssignedToTech' is equal to 'TR.AssignedToTech' != 'DB.AssignedToTech' and 'TR.AssignedToTech' != $NULL$ this qual 'AssignedToTech' != 'DB.AssignedToTech' AND 'TR.AssignedToTech' != $NULL$ is redundant. On Thu, Apr 15, 2010 at 12:02 PM, Tanner, Doug <[email protected]<mailto:[email protected]>> wrote: Foolproof method (assuming the field is NOT required at the database level) 'AssignedToTech' != 'DB.AssignedToTech' AND 'TR.AssignedToTech' != $NULL$ -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Brien Dieterle Sent: Thursday, April 15, 2010 12:50 PM To: [email protected]<mailto:[email protected]> Subject: Re: TR vs DB sanity check please Maybe add an AND 'TR.AssignedToTech' != $NULL$ Brien On 4/15/2010 9:28 AM, Drew Shuller wrote: > I typed the email wrong. > > I've tried the Run If as both 'TR.AssignedToTech' != 'DB.AssignedToTech' > and without the TR in the first instance. > > I'm running a Notify action. I do get inconsistent results. > > Drew > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at > www.arslist.org<http://www.arslist.org/> > attend wwrug10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the > Answers Are" > > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org/> attend wwrug10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are" DISCLAIMER Important! This message is intended for the above named person(s) only and is CONFIDENTIAL AND PROPRIETARY. If you are not the intended recipient of this e-mail and have received it in error, please immediately notify the sender by return email and then delete it from your mailbox. This message may be protected by the attorney-client privilege and/or work product doctrine. Accessing, copying, disseminating or re-using any of the information contained in this e-mail by anyone other than the intended recipient is strictly prohibited. Finally, you should check this email and any attachments for the presence of viruses, as the sender accepts no liability for any damage caused by any virus transmitted by this email. Thank you. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org/> attend wwrug10 www.wwrug.com<http://www.wwrug.com/> ARSlist: "Where the Answers Are" _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
