Thad, I'm glad there's at least one person in the world who has settled on the same rule regarding use of TR values. Don't!
Cause it's not necessary. There's no qualification you can't build without using TR. It's nothing but trouble. TR values tend to confuse people, as is evident from this thread. Even if you completely understand the nuances, there are many instances (many ways data can change) in which TR value will not be what you think. TR values give you what you expect only if the update is being done in Remedy user from a record that is "on display". If the update is being done from a dialog (common in ITSM 6), or if workflow is doing a query to get values and then pushing it back, use of TR values will drive you crazy. Why do you want to be driven crazy, I ask. There are enough opportunities to be driven crazy other ways. It has been around 5 years since I stopped using TR values. In with 'Field Name' != 'DB.Field Name' In with 'Field Name' != 'DB.Field Name' AND 'Field Name'!= $NULL$ Out with 'TR.Field Name' = $NULL$ (which misses blanking out of data anyway) --- Thad K Esser <[EMAIL PROTECTED]> wrote: > 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)" > <arslist@ARSLIST.ORG> > 10/03/2007 07:55 AM > Please respond to > arslist@ARSLIST.ORG > > > To > arslist@ARSLIST.ORG > 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: arslist@ARSLIST.ORG > 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: arslist@ARSLIST.ORG > 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: arslist@ARSLIST.ORG > 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: arslist@ARSLIST.ORG > > 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 > === message truncated === ____________________________________________________________________________________ Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get listings, and more! http://tv.yahoo.com/collections/3658 _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
