Hi,
As discussed earlier, the TR-values are not foolproof to find a change.
Because of this you cant just redesign to use TR-values instead of 'DB.Field'
and 'Field' (Most Current) values.
Best Regards - Misi, RRR AB, http://rrr.se
> Misi,
>
> In regards to the argument that using TR values improves performance... if
> the performance gain was measurable, then the logical extension of that
> would be to re-engineer the Run-IFs of every filter in the system so that
> they all use a TR value to avoid that database read. There is a long list
> of performance enhancing things that can be done before getting to that
> point.
>
> Randeep, I have no sympathy for the TR value. I'll keep beating up on it
> until I stop seeing TR values in code from BMC. More than once, it has
> been the cause of issues.
>
> Thad
>
>
>
> On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky <m...@rrr.se> wrote:
>
>> Hi,
>>
>> The only reason I can see for this is something I said in one of the other
>> zillion messages to this thread.
>>
>> When you have anything but 'TR.Field' in the run-if clauses of filters, the
>> system will do a fetch of that fields DB-value before the filters are
>> processed.
>>
>> So it could be a performance benefit to use ('TR.Field' != $NULL$).
>>
>> In most cases the gain will be very small, but I guess it could matter
>> sometimes.
>>
>> 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.
>>
>> > 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"
>> >>
>> >
>> >
>> _______________________________________________________________________________
>> > 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"
