Hi,
Just note that 'Field' and 'DB.Field' will cause exactly the same result. This
is because the 'Field' (most current value) will need to know the DB value to
work.
Best Regards - Misi, RRR AB, http://rrr.se
> Hi Randeep & Misi,
>
> I've performed a few tests and confirmed your propositions that the 'DB.'
> construct causes a DB read. In a SQL log I can see a DB read before the
> UPDATE only when I have a 'DB.' filter active (but not when I just have one
> using 'TR.').
>
> This is interesting and something I wasn't aware of and hadn't considered.
> It certainly has only a very narrow potential usage, but I agree there may
> be times when it'll come in handy as a performance boost.
>
> Another interesting aspect of this is that ARS seems to read the entire
> record, even though only one field is being used in one 'DB.'
> qualification. So, I guess if you absolutely must use 'DB.' construct
> anywhere in the filter sequence for a form, you may as well use it
> everywhere.
>
> I also tried turning off all of the triggers of the filter that had the
> 'DB.' qualification (i.e. there was no way it could be executed), and ARS
> still performed the DB read. But, of course, the server can't *know* that
> the filter can't run...it might be called in a guide somewhere. So this
> makes sense.
>
> So, it seems that if you have *any* active filter associated with a form
> that uses a 'DB.' construct in it's qualification, ARS is going to perform
> a full read of the record before filter processing.
>
> -charlie
>
>
>
> On Mon, May 19, 2014 at 6:04 AM, Misi Mladoniczky <[email protected]> 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 <[email protected]> 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 <[email protected]> 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:[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"
>> >> >>
>> >> >
>> >> >
>> >>
>> _______________________________________________________________________________
>> >> > 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"
