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"
<<inline: graycol.gif>>
<<inline: ecblank.gif>>
<<inline: pic26080.gif>>
