Also, it could have a value if the record update is the result of a push
fields from somewhere else. One way to get a handle on this is to run a
short SQL log and find the update statements. If a field is included in
the SET clause, the "TR" concept applies, whatever the actual value.
My two rules for TR and DB values:
1. Don't use TR values (DB values are useful & good).
2. If you need to use a TR value, see rule #1.
Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard
Bach
"Mayfield, Andy L." <[EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)"
<[email protected]>
10/03/2007 07:55 AM
Please respond to
[email protected]
To
[email protected]
cc
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)
> __20060125_______________________This posting was submitted
> with HTML in it___ __20060125_______________________This
> posting was submitted with HTML in it___
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
the Answers Are"
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org 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.***
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
