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"
