Re: TR vs DB sanity check please
Hi, Sorry, but this is not true. This tracks all changes: 'AssignedToTech' != 'DB.AssignedToTech' This tracks all changes if the field is not changed TO $NULL$: 'TR.AssignedToTech' != 'DB.AssignedToTech' and 'TR.AssignedToTech' != $NULL$ If this is a Resuired field, the end result would be the same. The redundancy of the last statement is true, but if you want to track that a change has occured to a non-null-value, I would write: 'AssignedToTech' != 'DB.AssignedToTech' AND 'AssignedToTech' != $NULL$ (i removed the TR on the last field) Best Regards - Misi, RRR AB, http://www.rrr.se Products from RRR Scandinavia: * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. 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 doug.tan...@compass-usa.comwrote: 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: arsl...@arslist.org] On Behalf Of Brien Dieterle Sent: Thursday, April 15, 2010 12:50 PM To: arslist@ARSLIST.ORG 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 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 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 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 -- This message was scanned by ESVA and is believed to be clean. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: TR vs DB sanity check please
Actually, that is not correct - the first two statements are NOT equal. The first statement will fire if AssignedToTech is set to $NULL$, and the database value is NOT $NULL$. The second statement will not. However, the second and third statements are essentially equivalent - they will both fire if the value is changed to any non-null value that doesn't match the database value. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of cpgold Sent: Thursday, April 15, 2010 4:27 PM To: arslist@ARSLIST.ORG 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 doug.tan...@compass-usa.commailto:doug.tan...@compass-usa.com 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:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent: Thursday, April 15, 2010 12:50 PM To: arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG 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.orghttp://www.arslist.org/ attend wwrug10 www.wwrug.comhttp://www.wwrug.com/ ARSlist: Where the Answers Are ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.orghttp://www.arslist.org/ attend wwrug10 www.wwrug.comhttp://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.orghttp://www.arslist.org/ attend wwrug10 www.wwrug.comhttp://www.wwrug.com/ ARSlist: Where the Answers Are _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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 From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of cpgold Sent: Thursday, April 15, 2010 3:27 PM To: arslist@ARSLIST.ORG 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 doug.tan...@compass-usa.commailto:doug.tan...@compass-usa.com 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:arslist@ARSLIST.ORGmailto:arslist@ARSLIST.ORG] On Behalf Of Brien Dieterle Sent
Re: TR vs DB sanity check please
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:arsl...@arslist.org] On Behalf Of Mueller, Doug Sent: Friday, April 16, 2010 1:17 PM To: arslist@ARSLIST.ORG 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
Re: TR vs DB sanity check please
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 attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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 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
Re: TR vs DB sanity check please
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:arsl...@arslist.org] On Behalf Of Brien Dieterle Sent: Thursday, April 15, 2010 12:50 PM To: arslist@ARSLIST.ORG 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 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 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 attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
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 doug.tan...@compass-usa.comwrote: 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: arsl...@arslist.org] On Behalf Of Brien Dieterle Sent: Thursday, April 15, 2010 12:50 PM To: arslist@ARSLIST.ORG 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 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 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 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
Re: TR vs DB sanity check please
Now if you only want to fire on a change in value not when a value goes from Null to being filled in then its 'AssignedToTech' != 'DB.AssignedToTech' AND 'DB.AssignedToTech' != $NULL$ On Thu, Apr 15, 2010 at 5:26 PM, cpgold cpg...@gmail.com wrote: 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 doug.tan...@compass-usa.com 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: arsl...@arslist.org] On Behalf Of Brien Dieterle Sent: Thursday, April 15, 2010 12:50 PM To: arslist@ARSLIST.ORG 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 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 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 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
TR vs DB sanity check please
Hello all, I've got one filter that checks for a change in a field called AssignedToTech that seems to be running even though the field didn't change. I ran a SQL log but didn't see any kind of insert statement that referenced that field. My Runif: 'AssignedToTech' != 'AssignedToTech' Sometimes the filter fires, sometimes it doesn't! I've got the run if right, don't I? -- Drew ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: TR vs DB sanity check please
Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Drew Shuller Sent: Wednesday, April 14, 2010 3:27 PM To: arslist@ARSLIST.ORG Subject: TR vs DB sanity check please Hello all, I've got one filter that checks for a change in a field called AssignedToTech that seems to be running even though the field didn't change. I ran a SQL log but didn't see any kind of insert statement that referenced that field. My Runif: 'AssignedToTech' != 'AssignedToTech' Sometimes the filter fires, sometimes it doesn't! I've got the run if right, don't I? -- Drew ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
Re: TR vs DB sanity check please
Drew, TR is implied as the current transaction value, and does not need to be explicitly mentioned. DB is not implied, and must be specified for consistent behavior. So the better Run If qual would be 'AssignedToTech' != 'DB.AssignedToTech' Rick On Wed, Apr 14, 2010 at 1:27 PM, Drew Shuller d...@io.com wrote: Hello all, I've got one filter that checks for a change in a field called AssignedToTech that seems to be running even though the field didn't change. I ran a SQL log but didn't see any kind of insert statement that referenced that field. My Runif: 'AssignedToTech' != 'AssignedToTech' Sometimes the filter fires, sometimes it doesn't! I've got the run if right, don't I? -- Drew ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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
Re: TR vs DB sanity check please
** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
Re: TR vs DB sanity check please
I understand how Rick put it that the TR is implied so you don't have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) _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
Re: TR vs DB sanity check please
If the field's value has not changed then the TR value is NULL while the DB value may not be NULL Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tommy Morris Sent: Wednesday, April 14, 2010 3:47 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** I understand how Rick put it that the TR is implied so you don't have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: TR vs DB sanity check please
Ahh, so without the TR specified it looks to the true current value instead of looking for an actual transaction? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Grooms, Frederick W Sent: Wednesday, April 14, 2010 3:50 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** If the field's value has not changed then the TR value is NULL while the DB value may not be NULL Fred From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Tommy Morris Sent: Wednesday, April 14, 2010 3:47 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** I understand how Rick put it that the TR is implied so you don't have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) _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
Re: TR vs DB sanity check please
** All fields that are specified in a push fields action are part of the TRansaction, and will therefore have a TR value, regardless of whether or not the value has changed. Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:48 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** I understand how Rick put it that the TR is implied so you dont have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ *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. * _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
Re: TR vs DB sanity check please
Ok, makes sense now. Thanks for the clarification. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** All fields that are specified in a push fields action are part of the TRansaction, and will therefore have a TR value, regardless of whether or not the value has changed. Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:48 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** I understand how Rick put it that the TR is implied so you don't have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG mailto:arslist@ARSLIST.ORG ] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ *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. * _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
Re: TR vs DB sanity check please
All fields in a Push Fields action are part of the push transaction yes, but for a standard modify of a form if they are not changed then the TR value is NULL. From the Workflow Objects PDF - Transaction Only-References the value of the field in the current transaction only. If the value is not changed in the transaction, it is considered to be $NULL$. If the operation is a delete, it is considered to be $NULL$. To specify a check of the transaction only, use the format 'TR.field' when you enter the field name in the Run If field. - Database Only-References the value of the field in the database only. No check is made of the value in the current transaction. If the operation is a create operation, it is considered to be $NULL$. To specify a reference of the database only, use the format 'DB.field' when you enter the field name in the Run If field. - Transaction and Database-References the value of the field in the current transaction and uses that value if changed. If not changed in the current transaction, references the value of the field in the database. To specify a reference of both the transaction and the database (in this order), use the format 'field' when you enter the field name in the Run If field. From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** All fields that are specified in a push fields action are part of the TRansaction, and will therefore have a TR value, regardless of whether or not the value has changed. Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:48 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** I understand how Rick put it that the TR is implied so you don't have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: TR vs DB sanity check please
** The TR value is also NULL if the field on the form was cleared. So in that case, the TR value is null, and the value has changed. There's just too many variations and gotchas to make using the TR value worthwhile. IMO. :-) Thad Esser Remedy Developer From: Grooms, Frederick W frederick.w.gro...@xo.com To: arslist@ARSLIST.ORG Date: 04/14/2010 02:09 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** All fields in a Push Fields action are part of the push transaction yes, but for a standard modify of a form if they are not changed then the TR value is NULL. From the Workflow Objects PDF - Transaction OnlyReferences the value of the field in the current transaction only. If the value is not changed in the transaction, it is considered to be $NULL$. If the operation is a delete, it is considered to be $NULL$. To specify a check of the transaction only, use the format 'TR.field' when you enter the field name in the Run If field. - Database OnlyReferences the value of the field in the database only. No check is made of the value in the current transaction. If the operation is a create operation, it is considered to be $NULL$. To specify a reference of the database only, use the format 'DB.field' when you enter the field name in the Run If field. - Transaction and DatabaseReferences the value of the field in the current transaction and uses that value if changed. If not changed in the current transaction, references the value of the field in the database. To specify a reference of both the transaction and the database (in this order), use the format 'field' when you enter the field name in the Run If field. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:58 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** All fields that are specified in a push fields action are part of the TRansaction, and will therefore have a TR value, regardless of whether or not the value has changed. Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:48 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG ** I understand how Rick put it that the TR is implied so you dont have to specify it but why would including the identifier cause an erroneous result? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Thad K Esser Sent: Wednesday, April 14, 2010 3:44 PM To: arslist@ARSLIST.ORG Subject: Re: TR vs DB sanity check please ** Tommy, In some situations, your version will evaluate to true, even though nothing changed. To truly detect if a value changed, its best to use: 'AssignedToTech' != 'DB.AssignedToTech' Thad Esser Remedy Developer From: Tommy Morris tommy.mor...@radioshack.com To: arslist@ARSLIST.ORG Date: 04/14/2010 01:39 PM Subject: Re: TR vs DB sanity check please Sent by: Action Request System discussion list(ARSList) arslist@ARSLIST.ORG Instead of Runif: 'AssignedToTech' != 'AssignedToTech' Make it Runif: 'TR.AssignedToTech' != 'DB.AssignedToTech' -Original Message- From: Action Request System discussion list(ARSList) _attend WWRUG10 www.wwrug.com ARSlist: Where the Answers Are_ *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. * _attend WWRUG10 www.wwrug.com ARSlist: "Where the Answers Are"_
Re: TR vs DB sanity check please
Oops. I typed the email wrong. I've tried the Run If as been 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 attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
Re: TR vs DB sanity check please
Hi,
('AssignedToTech' != 'DB.AssignedToTech') will allways detect a change.
('AssignedToTech' != 'DB.AssignedToTech' AND 'AssignedToTech' != $NULL$)
when you want to check for a change to a non-null-value.
The execution order of your filters, and filter phasing, may play tricks
with you. A value can be changed by another filter after your check was
done.
I suggest that you turn on both API/FLTR/SQL-logging to track this down.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
Oops. I typed the email wrong. I've tried the Run If as been 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
attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
--
This message was scanned by ESVA and is believed to be clean.
___
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: Where the Answers Are
