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"
