I appreciate this topic coming up - I wasn't aware of the TR issue when pushing a value.
After reading this, I'm inclined to use 'TR.Status' = "Fixed" AND 'Status' != 'DB.Status' though I can't claim any performance advantage with that. Does anyone see an issue with that? It leaves the transaction check in there (Status != DB.Status), with only 1 value to change if you want to update the filter to check for another value. David Durling Enterprise IT Services University of Georgia On Tue, 16 Jan 2007 09:43:47 -0700, L. J. Head <[EMAIL PROTECTED]> wrote: >Plus....if I remember correctly from Performance and Tuning class back in >the 4.x days then Remedy will stop processing a qualification on the first >failure...so in that example below if 'TR.Status' != "Fixed" then it never >even checks the second half of the qualification...which saves another call >all together....:) > >-----Original Message----- >From: Action Request System discussion list(ARSList) >[mailto:[EMAIL PROTECTED] On Behalf Of Opela, Gary L Contr OC-ALC/ITMA >Sent: Tuesday, January 16, 2007 9:34 AM >To: [email protected] >Subject: Re: When is TR valid > >I stay away from TR because of the two points below pointed out by everyone >else: > >TR.Field = $NULL$ if the field is blanked out TR.Field != $NULL$ If field is >pushed the same value to itself > >The two above points have caused too much heartache, so I stay away. > >However, LJ pointed out that if you are doing > >'TR.Status' = "Fixed" AND 'DB.Status' != "Fixed > >Then using TR will save you a database call if there is no transaction value >to start out with. This is very interesting. > >Thanks for pointing this out LJ, and redeeming some of the usefulness of TR. > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
