Hi Axton,
The Client-API sends transaction values to the server for those fields
decided by the Client. The values sent are those values that the client
would like stored in the DB. The server does not need to know anything but
the transaction values, to store these values.
The problem is that the fields not sent by the client (TR-values), in a
filter-run-if, is the same as those fields not sent in the transaction,
i.e. NULL.
To determine if a change has really occored, the filter has to access the
database.
The most current value (syntax 'Field') or the DB-value (syntax
'DB.Field') both need to access the database, as only some fields may have
been sent from the client.
I have made a new log output that proves this.
The only enabled filter is one with the following run-if:
('Assigned To' = $NULL$)
http://www.rrr.se/tmp/TestAssignedToMostCurrent.html
And for comparison.
('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
My point is that it is no difference between using 'Field' or 'DB.Field'
The other important thing is that it suffice to have one filter with the
syntax of 'Field' or 'DB.Field' to bring the whole transaction. If you ad
1 or 100 such filters does not matter, as:
1. There will be only one database select issued
2. The select statement will bring in all fields regardless of the number
of fields in filter-run-ifs
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.
> 'Field' will not cause a read from the db, only 'DB.Field'. All the
> current transaction values are already available on the Remedy side,
> how else would Remedy know what to write to the db?
>
> Axton
>
> On 10/4/07, Misi Mladoniczky <[EMAIL PROTECTED]> wrote:
>> 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"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the
Answers Are"
