While the TR is confusing isn't there a performance benefit? If I remember correctly a TR check will not run a query against the database (I haven't actually logged it to verify).
Say you run a daily import of 500k employees (the requirement is to do it during the business hours for whatever reason) and are looking to see if their employment status has changed, if so create a request to take action. The import will perform an initial query the DB to find the existing record to update but then you have a filter that runs if 'EMP_Status' != 'DB.EMP_Status' (a required field). Wouldn't that cause an additional query on the database to retrieve the record you just retrieved? Using 'EMP_Status' != 'TR.EMP_Status' would check the server's memory if the value has changed and eliminate a redundant trip to the DB. In this case using a TR would eliminate 500k less queries to the database. During business hours that may be a huge savings (so I added the business hours part to help my example). Is my scenario correct? Jason -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Wednesday, October 03, 2007 6:09 PM To: [email protected] Subject: Re: Filter Problem 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)" > <[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 > === 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" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
