Misi, In regards to the argument that using TR values improves performance... if the performance gain was measurable, then the logical extension of that would be to re-engineer the Run-IFs of every filter in the system so that they all use a TR value to avoid that database read. There is a long list of performance enhancing things that can be done before getting to that point.
Randeep, I have no sympathy for the TR value. I'll keep beating up on it until I stop seeing TR values in code from BMC. More than once, it has been the cause of issues. Thad On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky <[email protected]> wrote: > Hi, > > The only reason I can see for this is something I said in one of the other > zillion messages to this thread. > > When you have anything but 'TR.Field' in the run-if clauses of filters, the > system will do a fetch of that fields DB-value before the filters are > processed. > > So it could be a performance benefit to use ('TR.Field' != $NULL$). > > In most cases the gain will be very small, but I guess it could matter > sometimes. > > Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) > > Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): > * RRR|License - Not enough Remedy licenses? Save money by optimizing. > * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. > Find these products, and many free tools and utilities, at http://rrr.se. > > > I'm curious, what's the 0.1% case when it would be useful? I'm just not > > seeing any unique use for it at all. > > > > -charlie > > > > > > On Sat, May 17, 2014 at 1:04 PM, Misi Mladoniczky <[email protected]> wrote: > > > >> Hi, > >> > >> It is up to the client. > >> > >> If this for example was done through a Push-Fields, 'TR.City' could > >> contain a > >> value even if it was not changed. The same could be done using a > >> Modify-All, > >> and I think it is possible to fool some clients by first changing the > field > >> value in the GUI and then change it back before pressing Save. > >> > >> As others have suggested, we should stay away from TR in 99.9% of the > >> cases. > >> > >> Best Regards - Misi, RRR AB, http://rrr.se > >> > >> > Misi, > >> > Joe's example stated > >> > > >> > Case 1: When there is no change in the 'City' value during the > >> modification. > >> > 'City' = "Gotham" > >> > 'TR.City' = $NULL$ (as there was no transnational change in the value) > >> > 'DB.City' = "Gotham" > >> > > >> > So, this isn't a modify to City...this is an existing record with City > >> > already populated...so I still say that Joe's analysis is correct :) > >> > > >> > > >> > On Sun, May 11, 2014 at 4:35 AM, Misi Mladoniczky <[email protected]> wrote: > >> > > >> >> Hi Joe and LJ, > >> >> > >> >> You are wrong on Case 1: > >> >> > >> >> If you set the City to "Gotham", it will have a TR-value of "Gotham" > >> even > >> >> on a > >> >> Create. > >> >> > >> >> Case 2 is nothing much to say about. > >> >> > >> >> The problem with the TR value is: > >> >> > >> >> A. If the value is NOT changed it can both be set or be empty during > a > >> >> Modify. > >> >> This depends on the client and how they use the API. For example a > >> >> Push-Fields > >> >> will always send a value, but a normal Save will only send a value > if it > >> >> has > >> >> been changed. > >> >> > >> >> B. A value that is changed to NULL can not be distinguished from a > value > >> >> that > >> >> is not sent in the transaction. Both situations will match a > 'TR.Field' > >> = > >> >> $NULL$. > >> >> > >> >> Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP > >> 2011) > >> >> > >> >> Ask the Remedy Licensing Experts (Best R.O.I. Award at > >> WWRUG10/11/12/13): > >> >> * RRR|License - Not enough Remedy licenses? Save money by optimizing. > >> >> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy > >> logs. > >> >> Find these products, and many free tools and utilities, at > >> http://rrr.se. > >> >> > >> >> > While most of everything you stated is in sync with my > understanding > >> of > >> >> TR, > >> >> > there is one small difference. MAYBE, I'm wrong and if so, I would > >> love > >> >> to > >> >> > be corrected. > >> >> > > >> >> > I can best explain this with an example. > >> >> > > >> >> > Lets say a record is created and there is a field called 'City' and > >> >> during > >> >> > creation, that field was set to "Gotham".. > >> >> > > >> >> > Case 1: When there is no change in the 'City' value during the > >> >> modification. > >> >> > 'City' = "Gotham" > >> >> > 'TR.City' = $NULL$ (as there was no transactional change in the > value) > >> >> > 'DB.City' = "Gotham" > >> >> > > >> >> > Case 2: When the value in the field 'City' is changed during a > >> >> modification > >> >> > to "Xanadu" > >> >> > 'City' = "Xanadu" > >> >> > 'TR.City' = "Xanadu" > >> >> > 'DB.City' = "Gotham" > >> >> > > >> >> > So according to my understanding, it is incorrect to say that > >> 'TR.City' > >> >> is > >> >> > the same as 'City' at all times. > >> >> > > >> >> > Cheers > >> >> > > >> >> > Joe > >> >> > > >> >> > > >> >> > -----Original Message----- > >> >> > From: Action Request System discussion list(ARSList) > >> >> > [mailto:[email protected]] On Behalf Of William Rentfrow > >> >> > Sent: Friday, May 09, 2014 9:28 AM > >> >> > To: [email protected] > >> >> > Subject: Re: Transactional (TR) and Database (DB) > >> >> > > >> >> > I think there's a few reasons. > >> >> > > >> >> > First, using TR. is redundant. Every value in a filter (unless it > >> >> already > >> >> > has DB. in front of it) is by it's nature a transactional value. > >> There's > >> >> > literally almost no reason to use, it, EXCEPT that it makes the > code a > >> >> bit > >> >> > more clear from a visual standpoint if you do decide to use DB. on > a > >> >> field. > >> >> > > >> >> > I think the reason most people don't use DB. on field workflow is > that > >> >> it's > >> >> > kind of perceived as lazy. Let's say you want to check and see if > a > >> >> phone # > >> >> > has changed. You can either use the Phone != DB.Phone at runtime > - or > >> >> you > >> >> > can do an actual lookup with some separate workflow prior to this > >> action. > >> >> > That gives you greater control over the action going on for the > most > >> >> part. > >> >> > > >> >> > That said, it's just my opinion and I'm sure there's lots of place > >> people > >> >> > have used both and been perfectly happy with it. > >> >> > > >> >> > -----Original Message----- > >> >> > From: Action Request System discussion list(ARSList) > >> >> > [mailto:[email protected]] On Behalf Of James Smith > >> >> > Sent: Thursday, May 08, 2014 10:22 AM > >> >> > To: [email protected] > >> >> > Subject: Transactional (TR) and Database (DB) > >> >> > > >> >> > Hi List, > >> >> > > >> >> > We can achieve things without using TR and DB values in a filter by > >> just > >> >> > using Field but I do not understand why they have been developed to > >> use? > >> >> I > >> >> > have heard from many remedy developers like Misi and BMC who > suggest > >> not > >> >> to > >> >> > use TR and DB in Run If qualification of a filter but why? > >> >> > > >> >> > Why it is not recommended to use TR and DB values? > >> >> > > >> >> > What if I use TR.Field=DB.Field? Will it yield a correct result? In > >> BMC > >> >> > documentation also they have not given any example where they used > TR > >> >> and DB > >> >> > together in a qualification. > >> >> > > >> >> > Appreciate your thoughts! > >> >> > > >> >> > Cheers, > >> >> > James > >> >> > > >> >> > > >> >> > >> > ____________________________________________________________________________ > >> >> > ___ > >> >> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> >> > "Where the Answers Are, and have been for 20 years" > >> >> > > >> >> > ----- > >> >> > No virus found in this message. > >> >> > Checked by AVG - www.avg.com > >> >> > Version: 2014.0.4570 / Virus Database: 3931/7443 - Release Date: > >> 05/05/14 > >> >> > > >> >> > > >> >> > >> > ____________________________________________________________________________ > >> >> > ___ > >> >> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> >> > "Where the Answers Are, and have been for 20 years" > >> >> > > >> >> > > >> >> > >> > _______________________________________________________________________________ > >> >> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> >> > "Where the Answers Are, and have been for 20 years" > >> >> > > >> >> > >> >> > >> >> > >> > _______________________________________________________________________________ > >> >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> >> "Where the Answers Are, and have been for 20 years" > >> >> > >> > > >> > > >> > _______________________________________________________________________________ > >> > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> > "Where the Answers Are, and have been for 20 years" > >> > > >> > -- > >> > This message was scanned by ESVA and is believed to be clean. > >> > > >> > > >> > >> > >> > _______________________________________________________________________________ > >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > >> "Where the Answers Are, and have been for 20 years" > >> > > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > > "Where the Answers Are, and have been for 20 years" > > > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
