Axton and Dave are right. My mistake earlier.. I validated what I stated on my last email and yes, TR = NULL when you reset a field back to NULL. My apologies for causing some confusion..
Like Axton said this often trips out many people. When in doubt you can run a simple test to verify TR values. Create a form, create filters with conditions for TR = NULL and TR != NULL, and verify the different conditions under which TR can be NULL and not NULL. Joe D'Souza -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Mayfield, Andy L. Sent: Wednesday, October 03, 2007 10:55 AM To: [email protected] Subject: Re: Filter Problem OK, I think after a few cups of coffee I am now able to comprehend this. TR.Field != $NULL$ should fire anytime the field is changed, unless it is actually set to NULL. That is rather confusing to simple minded folk such as myself (-: Andy L. Mayfield Sr. System Operation Specialist Alabama Power Company Office: 8-226-1805 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David Sent: Wednesday, October 03, 2007 9:16 AM To: [email protected] Subject: Re: Filter Problem Andy, As Axton said TR.field really is the value of the transaction. If a field doesn't change then the TR.field is null. There isn't a transaction because the DB.field and field are the same. If a field changes TR.field evaluates to what was just entered. So if you change a field from Hello World to Good Morning, TR.field will evaluate to Good Morning, DB.field evaluates to Hello World, and the field evaluates to Good Morning. The tricky one is where the field was Hello World but is now set to NULL. The DB.field is Hello World and the field value is NULL. Because there is a change there is a transaction but the TR.field evaluates to NULL because the field is actually set to NULL. Dave -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Mayfield, Andy L. Sent: Wednesday, October 03, 2007 10:06 AM To: [email protected] Subject: Re: Filter Problem I thought everyone was saying that if I set a field to NULL (that previously had a value), the TR value would NOT be NULL? I am getting confused. I may need to take a break for coffee and a cigarette to clear my head (-: >Andy L. Mayfield Sr. System Operation Specialist >Alabama Power Company Office: 8-226-1805 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Wednesday, October 03, 2007 8:41 AM To: [email protected] Subject: Re: Filter Problem This one that probably often trips people up; if you set the field to null, the TR value will be null. The TR value represent the current transactions value, if no change occurred in the transaction, then the TR value is null The DB value represents what was last committed to the database; prior to the current transaction The value represents the current value, regardless of the TR or DB values Axton Grams On 10/3/07, Mayfield, Andy L. <[EMAIL PROTECTED]> wrote: > ** > > > > OK, I thought I had this figured. So if while modifying a ticket, you > change a field that previously had a value, to NULL (blank) then the TR > value is NOT NULL. > > > > I need more coffee. > > > > > Andy L. Mayfield > Sr. System Operation Specialist > Alabama Power Company > Office: 8-226-1805 > > ________________________________ > > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza > Sent: Tuesday, October 02, 2007 10:57 PM > > To: [email protected] > Subject: Re: Filter Problem > > > > > > Yes the TR value is NULL if there is no modification even if there is a DB > value to that field.. > > > > > > This is how it works.. when you are submitting a new record, and if there is > a value in the field, then the TR value is not NULL (obviously). The DB > value is always NULL at the time of submission of a ticket (again > obviously). > > > > > > However when you are modifying a ticket, if the DB value is NOT NULL, but > you haven't changed that value, then the TR value is NULL (although that > doesn't look that obvious). > > > > > > When you are modifying the ticket, and the DB value is NOT NULL, and you > change the DB value to a NON NULL value, then the TR value is NOT NULL. > > > > > > Another case is when you are modifying the ticket and the DB value is NOT > NULL, but you change that to a NULL value, then the TR value again is NOT > NULL. > > > > > > > Joe D'Souza > > > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Mayfield, Andy L. > Sent: Tuesday, October 02, 2007 9:57 PM > To: [email protected] > Subject: Re: Filter Problem > > > I did not realize that the TR. value would = $NULL$ just because it was not > being modified, when it already contained a value. It makes sense now that I > think about it. > > The 'AssignedConfigTech' can possibly be set to $NULL$, but in that case I > do not want the filter to fire. > > Andy L. Mayfield > Sr. System Operation Specialist > Alabama Power Company > Office: 8-226-1805 > > ________________________________ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David > Sent: Tuesday, October 02, 2007 8:04 PM > To: [email protected] > Subject: Re: Filter Problem > > > > > > You need to be careful that the AssignedConfigTech can't be set to NULL. > If it is the TR.AssignedConfigTech will resolve to NULL. > > Dave > -------------------------- > [EMAIL PROTECTED] (Wireless) No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.488 / Virus Database: 269.14.0/1046 - Release Date: 10/3/2007 10:08 AM _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
