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"
