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"
