Hi Mike,
You are right. In reality, the performance benefits of DB-values are
unimportant.
Use ('Field' != 'DB.Field') to detect a change.
Use ('Field' != 'DB.Field' AND 'Field' != $NULL$) on optional fields if
you do not want to trigger workflow when the field is set to NULL.
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.
> Very interesting discussion of performance aspects of TR and DB values.
> In
> the case where you need to trigger code on behalf of a change to a field,
> and the change can be made either directly by the user, or indirectly via
> intermediate workflow, isn't it a moot point? Is there an alternative to
> 'TR.xxx' != $NULL and 'xxx' != 'DB.xxx' (or simply 'xxx' != 'DB.xxx', as
> was offered earlier)?
>
> Mike White
> Office: 813-978-2192
> E-mail: [EMAIL PROTECTED]
>
>
>
> Misi Mladoniczky
> <[EMAIL PROTECTED]> To:
> [email protected]
> Sent by: "Action cc:
> Request System Subject: Re: Filter
> Problem
> discussion
> list(ARSList)"
> <[EMAIL PROTECTED]
> ORG>
>
>
> 10/04/2007 06:43
> Please respond to
> arslist
>
>
>
>
>
>
> Hi,
>
> Just remember that 'DB.Field' and 'Field' both results in an fetch from
> the database. How else can the 'Field' (most current) be computed!
>
> Another issue to concider is that if any Filter-Set-Fields on CURRENT
> TRANSACTION are referencing fields, e.g. $Field$, the complete record is
> also fetched from the databas.
>
> My point is that it is very rare to have a form with:
> 1. Filter run-ifs with only references to TR-values only
> 2. No filter actions triggered that reference fields, where database
> values may be required
>
> If any of the above things are true, the complete set of fields will be
> retrieved.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se/sv/
>
>> That was my understanding of DB.field also.
>>
>>
>>
>> I havenââ¬â¢t taken the Performance Tuning class. Does the class
>> cover what
>> the difference is between TR and DB and when to use either one?
>>
>>
>>
>> DB may be an efficient search but still a search where as TR would not
>> be
>> a search, correct? Even searching by the known record number in a
>> really
>> large table still could take some time. Multiply that by tens of
> thousands
>> of records in the import scenario and it really starts adding up.
>>
>>
>>
>> Jason
>>
>>
>>
>> From: Action Request System discussion list(ARSList)
>> [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, David
>> Sent: Wednesday, October 03, 2007 9:09 PM
>> To: [email protected]
>> Subject: Re: Filter Problem
>>
>>
>>
>> DB.Field has to query the database. By definition it is the data
>> that's
>> stored in the field in the database.
>>
>>>From my Performance Tuning class several years ago, Lincoln noted that
>>> it
>>> was an efficient search because the record number is already known.
>>
>> Dave
>> --------------------------
>> [EMAIL PROTECTED] (Wireless)
>>
>> ----- Original Message -----
>> From: Action Request System discussion list(ARSList)
>>
> _______________________________________________________________________________
>
>> 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"
