Agreed. On May 10, 2014 1:08 PM, "Joe D'Souza" <[email protected]> wrote:
> 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"
