Re: Transactional (TR) and Database (DB)

[Randeep Atwal]

** I can't think of anything that has ever come up as a requirement that I would need it for. BUT, (and i'm reaching here. :-) treating your question as a teaser Charlie. If someone had a requirement that a message should be popped to users of the user tool or mid-tier when they were modifying an existing record and using the save feature of those clients, that they or other workflow has successfully either modified a value or edited a value and then edited it back to what it was, and we need to do so without incurring a database read, that would be the reason. So pretty much never, unless this requirement came up, which I can think of no earthly reason it would come up. are we done yet beating up on the poor old TR value, we have hurt it's feelings enough I think.  :-) There probably once was a reason for it, I remember once back in a performance tuning class we were encouraged to use it to avoid an extra read to the DB. But I think at some poi‎nt ARServer started storing all db values in memory for the transaction after the first db.value was referenced in a filter.  That is speculation however. From: Charlie Lotridge Sent: Sunday, May 18, 2014 10:44 AM To: arslist@ARSLIST.ORG Reply To: arslist@ARSLIST.ORG Subject: Re: Transactional (TR) and Database (DB) ** 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 <m...@rrr.se> 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 <m...@rrr.se> 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:arslist@ARSLIST.ORG] On Behalf Of William Rentfrow >> > Sent: Friday, May 09, 2014 9:28 AM >> > To: arslist@ARSLIST.ORG >> > 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:arslist@ARSLIST.ORG] On Behalf Of James Smith >> > Sent: Thursday, May 08, 2014 10:22 AM >> > To: arslist@ARSLIST.ORG >> > 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" _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_