I said this last week, I'll say it again: to blindly use one approach is to be blind. There are certain benefits using TR when other methods could suffice. The trick is knowing when and how to use them.
Any time you use a DB value in your filter qualification, you take another round trip to the db and add another query to the db from the app server. TR values work great, esp. with required fields and fields that were previously null. Think about these two scenarios: - you need to check for a change to a required field, options include: * 'value' != 'DB.value' :: causes 1 more db query than the other option * 'TR.value' != 'value' - you need to check when a value is assigned to a field: * 'DB.value' = $ NULL$ and 'value' != $ NULL$ * 'TR.value' != $ NULL$ I know there are other scenarios, but these two stick out. You may say, well, it's just one query to the db, and it uses the request id to look up the value. Think about it like this: what if you can reduce the calls to the db by a factor of 5% through the efficient use of TR, now let's say you have an escalation that runs against your 10k record data set, you've reduced the number of queries and the overall execution time by a significant margin. Axton Grams On 10/3/07, Rabi Tripathi <[EMAIL PROTECTED]> wrote: > 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"
