Hi Dave,
The problem here is that a TR value van be NULL, but is still part of the
transaction.
All fields not part of the transaction will also have a TR value of NULL.
The statement "Only new or changed field values are part of a
transaction." is wrong.
TR-values can be set in a number of other ways, where the TR value and DB
value are the same:
- Modify-All
- Push-Fields
- Set-fields-filter that sets a field to the same value as in the DB
- Other API-programs
These two ways of checking for a change has the same effect, but I prefer
the first one:
('Field' != 'DB.Field' AND 'Field' != $NULL$)
('TR.Field' != 'DB.Field' AND 'TR.Field' != $NULL$)
If you want to track a change that includes a change to NULL, there is
only one (simple) way of doing it:
('Field' != 'DB.Field)
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.
> Esser,
>
> TR indeed have some usefulness. Following is taken straight from page 36
> of
> "Work-Flow Objects-700.pdf" We have a few filters that need to fire ONLY
> if
> that particular value is changed in a given transaction and it fires as
> intended and doesn't fire when it shouldn't. It works fine for me.
>
>
> For filters, you can specify whether the qualification is to reference
> field
> values in the transaction only, in the database only, or in both:
> To check the value for the transaction only, enter the field name as
> 'TR.<field>' (for example, 'TR.Submitter').
> To check the value in the database only, enter the field name as
> 'DB.<field>'
> (for example, 'DB.Submitter').
> To check the value for the transaction first and then check the database
> if
> a new value is not found in the transaction, enter the field name with no
> prefix.
> Only new or changed field values are part of a transaction.
> The TR and DB prefixes work only in filter Run If qualifications.
>
> If we do 'Field' != DB.Field and if the value is not changed in a
> transaction, it'll always be false (according to the guidelines from BMC
> above) and we should be usingTR.Field != $NULL$, shouldn't we?? At least
> that was my understanding and I'm still new to ARS.
>
> Thank you,
>
> Dave.
>
>
> Thad K Esser wrote:
>>
>> 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)"
>> <arslist@ARSLIST.ORG>
>> 10/04/2007 03:31 AM
>> Please respond to
>> arslist@ARSLIST.ORG
>>
>>
>> To
>> arslist@ARSLIST.ORG
>> 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: arslist@ARSLIST.ORG
>>> 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)"
>>>> <arslist@ARSLIST.ORG>
>>>> 10/03/2007 07:55 AM
>>>> Please respond to
>>>> arslist@ARSLIST.ORG
>>>>
>>>>
>>>> To
>>>> arslist@ARSLIST.ORG
>>>> 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: arslist@ARSLIST.ORG
>>>> 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: arslist@ARSLIST.ORG
>>>> 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: arslist@ARSLIST.ORG
>>>> 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: arslist@ARSLIST.ORG
>>>> > 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"
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Filter-Problem-tf4558880.html#a13047946
> Sent from the ARS (Action Request System) mailing list archive at
> Nabble.com.
>
> _______________________________________________________________________________
> 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"
