Hi,
The discussion today has pretty much ruled out any significant performance
benefit. I agree.
The ('TR.Assigned To' != $NULL$) is sometimes enough...
The more accurat, and slightly more complex to read ('Assigned To' !=
'DB.Assigned To' AND 'Assigned To' != $NULL$) is preferred.
It was a long long time since I used anything but the last syntax.
Push-Fields breaks the simplified syntax, but Push-Fields has not been
here such a long time, has it? Macros using Modify-All was the biggest
problem before Push-Fields came around ;-)
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
> Misi,
>
> I respectfully (and adamantly) disagree with your comment: "I think that
> the TR-values can have a legitimate use sometimes. Either for the reason
> of performance, or the reason of simplifying your run-ifs".
>
> Using a TR value does NOT simplify your Run-Ifs, it actually makes them
> more complicated and trickier to understand. I used to use a sig file of:
> "Perfection is achieved, not when there is nothing more to add,
> but when there is nothing left to take away." - Antoine de Saint-Exupéry
>
> By using the TR value alone, accuracy is lost (too much has been taken
> away). In your three examples, you acknowledge as much:
>
> Example 1: "It does not matter much if this filter sometimes run when it
> is not really necessary."
> If we are using TR values to improve performance, shouldn't we
> strive to eliminate unnecessary actions?
>
> Example 2: "...an extra notification is sent, but does no real damage.
> What if someone is going to order a server based on this email. Or
> call the help desk and rant that they already did this approval. Its very
> much situational as to what damage is done by an extra notification, but
> again, if performance is the goal, this fails.
>
> Example 3: "Extra controls may happen, but does not affect things much."
> Not much. People love it when computers do random things. (yes,
> this is tongue in cheek, call it pre-friday humor)
>
> Anyway, I just don't see performance as a valid issue for using a TR
> value.
>
> Thad Esser
> Remedy Developer
> "Argue for your limitations, and sure enough, they're yours."-- Richard
> Bach
>
>
>
> "Misi Mladoniczky" <[EMAIL PROTECTED]>
> Sent by: "Action Request System discussion list(ARSList)"
> <[email protected]>
> 10/04/2007 03:31 AM
> Please respond to
> [email protected]
>
>
> To
> [email protected]
> cc
>
> Subject
> Re: Filter Problem
>
>
>
>
>
>
> Hi,
>
> You are correct in the assumption that TR-values can save a little bit on
> performance.
>
> The server looks through the run-if-qualification of all filters.
>
> If anywhere there is a 'Field' or 'DB.Field', the server will need fetch
> these values from the database. And the values of all other fields of the
> form as well!
>
> If you only have 'TR.Field', static values or keywords. This fetch is not
> needed.
>
> Note that my test form has a lot of fields, and only two filters. One is
> disabled and one is enabled in the samples below:
>
> ('TR.Assigned To' != $NULL$)
> http://www.rrr.se/tmp/TestAssignedToTR.html
>
> ('Assigned To' != 'DB.Assigned To' AND 'Assigned To' != $NULL$)
> http://www.rrr.se/tmp/TestAssignedToDB.html
>
> All fields will be fetched as soon as you have one 'Field' or 'DB.Field'
> in your filters, so adding fields will do nothing to performance.
>
> I have noticed this behaviour in previous versions. The verion I am
> testing is version 7.0.1 patch 003.
>
> I think that the TR-values can have a legitimate use sometimes. Either for
> the reason of performance, or the reason of simplifying your run-ifs:
>
> Example 1: ('TR.CustID' != $NULL$)
> Your filter makes sure that the CustName is in sync with your CustID. It
> does not matter much if this filter sometimes run when it is not really
> neccessary.
>
> Example 2: ('TR.Assigned To' != $NULL$ AND 'TR.Assigned To' != $USER$)
> Your filter sends a notification to the assigned person. If the field has
> not really been changed, an extra notification is sent, but does no real
> damage.
>
> Example 3: ('TR.Status' != $NULL$)
> Your filter controls something or other connected with the status. Extra
> controls may happen, but does not affect things much.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se
>
> Products from RRR Scandinavia:
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> * RRR|Translator - Manage and automate your language translations.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> While the TR is confusing isn't there a performance benefit? If I
> remember
>> correctly a TR check will not run a query against the database (I
> haven't
>> actually logged it to verify).
>>
>> Say you run a daily import of 500k employees (the requirement is to do
> it
>> during the business hours for whatever reason) and are looking to see if
>> their employment status has changed, if so create a request to take
>> action.
>>
>> The import will perform an initial query the DB to find the existing
>> record
>> to update but then you have a filter that runs if 'EMP_Status' !=
>> 'DB.EMP_Status' (a required field). Wouldn't that cause an additional
>> query
>> on the database to retrieve the record you just retrieved? Using
>> 'EMP_Status' != 'TR.EMP_Status' would check the server's memory if the
>> value
>> has changed and eliminate a redundant trip to the DB. In this case using
> a
>> TR would eliminate 500k less queries to the database. During business
>> hours
>> that may be a huge savings (so I added the business hours part to help
> my
>> example).
>>
>> Is my scenario correct?
>>
>> Jason
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi
>> Sent: Wednesday, October 03, 2007 6:09 PM
>> To: [email protected]
>> Subject: Re: Filter Problem
>>
>> Thad, I'm glad there's at least one person in the
>> world who has settled on the same rule regarding use
>> of TR values. Don't!
>>
>> Cause it's not necessary. There's no qualification you
>> can't build without using TR. It's nothing but
>> trouble.
>>
>> TR values tend to confuse people, as is evident from
>> this thread. Even if you completely understand the
>> nuances, there are many instances (many ways data can
>> change) in which TR value will not be what you think.
>>
>> TR values give you what you expect only if the update
>> is being done in Remedy user from a record that is "on
>> display". If the update is being done from a dialog
>> (common in ITSM 6), or if workflow is doing a query to
>> get values and then pushing it back, use of TR values
>> will drive you crazy. Why do you want to be driven
>> crazy, I ask. There are enough opportunities to be
>> driven crazy other ways.
>>
>> It has been around 5 years since I stopped using TR
>> values.
>>
>> In with 'Field Name' != 'DB.Field Name'
>>
>> In with 'Field Name' != 'DB.Field Name' AND 'Field
>> Name'!= $NULL$
>>
>> Out with 'TR.Field Name' = $NULL$ (which misses
>> blanking out of data anyway)
>>
>> --- Thad K Esser <[EMAIL PROTECTED]> wrote:
>>
>>> Also, it could have a value if the record update is
>>> the result of a push
>>> fields from somewhere else. One way to get a handle
>>> on this is to run a
>>> short SQL log and find the update statements. If a
>>> field is included in
>>> the SET clause, the "TR" concept applies, whatever
>>> the actual value.
>>>
>>> My two rules for TR and DB values:
>>> 1. Don't use TR values (DB values are
>>> useful & good).
>>> 2. If you need to use a TR value, see rule
>>> #1.
>>>
>>> Thad Esser
>>> Remedy Developer
>>> "Argue for your limitations, and sure enough,
>>> they're yours."-- Richard
>>> Bach
>>>
>>>
>>>
>>> "Mayfield, Andy L." <[EMAIL PROTECTED]>
>>> Sent by: "Action Request System discussion
>>> list(ARSList)"
>>> <[email protected]>
>>> 10/03/2007 07:55 AM
>>> Please respond to
>>> [email protected]
>>>
>>>
>>> To
>>> [email protected]
>>> cc
>>>
>>> Subject
>>> Re: Filter Problem
>>>
>>>
>>>
>>>
>>>
>>>
>>> OK, I think after a few cups of coffee I am now able
>>> to comprehend this.
>>>
>>> TR.Field != $NULL$ should fire anytime the field is
>>> changed, unless it
>>> is actually set to NULL.
>>>
>>> That is rather confusing to simple minded folk such
>>> as myself (-:
>>>
>>> Andy L. Mayfield
>>> Sr. System Operation Specialist
>>> Alabama Power Company
>>> Office: 8-226-1805
>>>
>>>
>>> -----Original Message-----
>>> From: Action Request System discussion list(ARSList)
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Shellman,
>>> David
>>> Sent: Wednesday, October 03, 2007 9:16 AM
>>> To: [email protected]
>>> Subject: Re: Filter Problem
>>>
>>> Andy,
>>>
>>> As Axton said TR.field really is the value of the
>>> transaction.
>>>
>>> If a field doesn't change then the TR.field is null.
>>> There isn't a
>>> transaction because the DB.field and field are the
>>> same.
>>>
>>> If a field changes TR.field evaluates to what was
>>> just entered. So if
>>> you change a field from Hello World to Good Morning,
>>> TR.field will
>>> evaluate to Good Morning, DB.field evaluates to
>>> Hello World, and the
>>> field evaluates to Good Morning.
>>>
>>> The tricky one is where the field was Hello World
>>> but is now set to
>>> NULL. The DB.field is Hello World and the field
>>> value is NULL. Because
>>> there is a change there is a transaction but the
>>> TR.field evaluates to
>>> NULL because the field is actually set to NULL.
>>>
>>> Dave
>>>
>>> -----Original Message-----
>>> From: Action Request System discussion list(ARSList)
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Mayfield,
>>> Andy L.
>>> Sent: Wednesday, October 03, 2007 10:06 AM
>>> To: [email protected]
>>> Subject: Re: Filter Problem
>>>
>>> I thought everyone was saying that if I set a field
>>> to NULL (that
>>> previously had a value), the TR value would NOT be
>>> NULL?
>>>
>>> I am getting confused. I may need to take a break
>>> for coffee and a
>>> cigarette to clear my head (-:
>>>
>>> >Andy L. Mayfield
>>> Sr. System Operation Specialist
>>> >Alabama Power Company
>>> Office: 8-226-1805
>>>
>>>
>>> -----Original Message-----
>>> From: Action Request System discussion list(ARSList)
>>> [mailto:[EMAIL PROTECTED] On Behalf Of Axton
>>> Sent: Wednesday, October 03, 2007 8:41 AM
>>> To: [email protected]
>>> Subject: Re: Filter Problem
>>>
>>> This one that probably often trips people up; if you
>>> set the field to
>>> null, the TR value will be null.
>>>
>>> The TR value represent the current transactions
>>> value, if no change
>>> occurred in the transaction, then the TR value is
>>> null
>>>
>>> The DB value represents what was last committed to
>>> the database; prior
>>> to the current transaction
>>>
>>> The value represents the current value, regardless
>>> of the TR or DB
>>> values
>>>
>>> Axton Grams
>>>
>>> On 10/3/07, Mayfield, Andy L.
>>> <[EMAIL PROTECTED]> wrote:
>>> > **
>>> >
>>> >
>>> >
>>> > OK, I thought I had this figured. So if while
>>> modifying a ticket, you
>>> > change a field that previously had a value, to
>>> NULL (blank) then the
>>> TR
>>> > value is NOT NULL.
>>> >
>>> >
>>> >
>>> > I need more coffee.
>>> >
>>> >
>>> >
>>> >
>>> > Andy L. Mayfield
>>> > Sr. System Operation Specialist
>>> > Alabama Power Company
>>> > Office: 8-226-1805
>>> >
>>> > ________________________________
>>> >
>>> >
>>> > From: Action Request System discussion
>>> list(ARSList)
>>> > [mailto:[EMAIL PROTECTED] On Behalf Of Joe
>>> D'Souza
>>> > Sent: Tuesday, October 02, 2007 10:57 PM
>>> >
>>> > To: [email protected]
>>> > Subject: Re: Filter Problem
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > Yes the TR value is NULL if there is no
>>> modification even if there is
>>> a DB
>>> > value to that field..
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > This is how it works.. when you are submitting a
>>> new record, and if
>>> there is
>>> > a value in the field, then the TR value is not
>>> NULL (obviously). The
>>> DB
>>>
>> === message truncated ===
>>
>>
>>
>>
>>
> ____________________________________________________________________________
>> ________
>> Catch up on fall's hot new shows on Yahoo! TV. Watch previews, get
>> listings,
>> and more!
>> http://tv.yahoo.com/collections/3658
>>
>>
> ____________________________________________________________________________
>> ___
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
>> the
>> Answers Are"
>>
>>
> _______________________________________________________________________________
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
>> the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
>
>
> ***IMPORTANT NOTICE: This communication, including any attachment,
> contains information that may be confidential or privileged, and is
> intended solely for the entity or individual to whom it is addressed. If
> you are not the intended recipient, you should delete this message and are
> hereby notified that any disclosure, copying, or distribution of this
> message is strictly prohibited. Nothing in this email, including any
> attachment, is intended to be a legally binding signature.***
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where
> the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
