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"
