Doug, I have tried to explain this MANY times but have never been able to do so as eloquently as you just did. That said, I will point all future questions about this subject (and there will continue to be questions) to your post.
From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 1:17 PM To: [email protected] Subject: Re: TR vs DB sanity check please ** 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 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
