Axton,
In your 3rd example,
** On modify with qual: 'TR.Assigned To' != $NULL$
What shows up in the log when you use 'Assigned To' in a push fields from
somewhere else to this record, pushing the value that is already in the
'Assigned To' field? If the goal of using a TR value is "to detect a
change in value", you'll find that the above is true when there is no
change.
(And are there any situations where you'd use TR and the goal is something
other than "to detect a change in field value")
Thad Esser
Remedy Developer
"Argue for your limitations, and sure enough, they're yours."-- Richard
Bach
"Axton" <[EMAIL PROTECTED]>
Sent by: "Action Request System discussion list(ARSList)"
<arslist@ARSLIST.ORG>
10/04/2007 11:26 AM
Please respond to
arslist@ARSLIST.ORG
To
arslist@ARSLIST.ORG
cc
Subject
Re: Filter Problem
I only see the db call if using DB. I chopped the log lines so they
are readable in most mail readers.
** On modify with qual: 'Assigned To' != $NULL$
+SE ARSetEntry -- schema zBug_TableDrag-SampleData entryId 00
UPDATE T1160 SET C4='aasdfaaaaaaa',C5='AGADMIN',C6=1191521727 WHE
OK
COMMIT WORK
-SE OK
+GE ARGetEntry -- schema zBug_TableDrag-SampleData entryId 00
SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1160 WHERE C1 = '000000000
OK
SELECT entryId,T0,U0,T1,U1,T2,U2,T3,U3,T4,U4 FROM H1160 WHERE ent
OK
-GE OK
** On modify with qual: 'DB.Assigned To' != $NULL$
+SE ARSetEntry -- schema zBug_TableDrag-SampleData entryId 00
SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1160 WHERE C1 = '000000000
OK
SELECT entryId,T0,U0,T1,U1,T2,U2,T3,U3,T4,U4 FROM H1160 WHERE ent
OK
UPDATE T1160 SET C4='aaasdfaaaaaaa',C5='AGADMIN',C6=1191521782 WH
OK
COMMIT WORK
-SE OK
+GE ARGetEntry -- schema zBug_TableDrag-SampleData entryId 00
SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1160 WHERE C1 = '000000000
OK
SELECT entryId,T0,U0,T1,U1,T2,U2,T3,U3,T4,U4 FROM H1160 WHERE ent
OK
-GE OK
** On modify with qual: 'TR.Assigned To' != $NULL$
+SE ARSetEntry -- schema zBug_TableDrag-SampleData entryId 00
UPDATE T1160 SET C4='aaasdfaaaaaaaa',C5='AGADMIN',C6=1191521833 W
OK
COMMIT WORK
-SE OK
+GE ARGetEntry -- schema zBug_TableDrag-SampleData entryId 00
SELECT C1,C2,C3,C4,C5,C6,C7,C8,0 FROM T1160 WHERE C1 = '000000000
OK
SELECT entryId,T0,U0,T1,U1,T2,U2,T3,U3,T4,U4 FROM H1160 WHERE ent
OK
-GE OK
Axton Grams
On 10/4/07, Misi Mladoniczky <[EMAIL PROTECTED]> wrote:
> Hi,
>
> As the logs show in my 7.0.1 examples, this is usually true.
>
> The only time it is not true is when no filter at all uses
> 'DB.Field'-syntax or 'Field'-syntax. If this is the case, no fetch is
> made, as it is not neccessary.
>
> You could argue that it the code should not retrieve more columns than
> neccessary, but they apparently decided to simplify things. It is better
> to get all fields from the database, even if only one is needed, as it
is
> likely that more fields are required later.
>
> The other time, where I think the system refrains from the fetch, is
when
> you have an early filter triggering on ('TR.Goto1000' = "Yes"), and then
> makes a GOTO 1000 action that skips the rest of the filters.
>
> The fetch appears to be done when the first filter is run where the
> DB-data is needed: http://www.rrr.se/tmp/TestAssignedToMostCurrent.html
>
> 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
.
>
> > As I recall from Lenny's Performance Tuning class this summer that
> > nothing on the Run If of a Filter causes an additional query of the
> > database. The database record is retrieved at the start of the
> > processing and used for comparison throughout the process.
> >
> > This is just for the Run If...the action items inside the filters can
> > and do perform additional queries of the database.
> >
> > Stephen
> > Remedy Skilled Professional
> >
> >> >
> >> > --- 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
***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"
