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 <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"
