As Thad points out the key to using TR is understanding when a Transaction occurs.
If some one creates a record then all fields have transactional values. If some one modifies a field, that field will have a transactional value including if the field is set to NULL. If workflow performs a push field or an escalation performs a set field or if an individual performs a modify all, the fields will have transactional values. The system doesn't make a comparison like when an individual changes an individual records. The system simply sets the field to the indicated value which may or may not be a different value. The system simply says I'm treating this as a transactional value. Dave -------------------------- [EMAIL PROTECTED] (Wireless) ----- Original Message ----- From: Action Request System discussion list(ARSList) <[email protected]> To: [email protected] <[email protected]> Sent: Thu Oct 04 17:25:45 2007 Subject: Re: Filter Problem ** Dave, Misi is correct in saying that this statement is wrong: "Only new or changed field values are part of a transaction." TR values do NOT detect change. The only reliable way to detect change is to compare the current value with what is stored in the database, i.e. ('Field' != 'DB.Field'). Sorry guys, but this is the one ARS topic that makes me rabid. 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 01:36 PM Please respond to [email protected] To [email protected] cc Subject Re: Filter Problem 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: >> >>>> 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 ***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.*** __20060125_______________________This posting was submitted with HTML in it___
