Hate to beat a dead horse but "( 'TR.Fieldname != $NULL$ ) AND ( 'Fieldname' != 'DB.Fieldname' )
"I want the filter to fire if the transactional value -- i.e., what the user just entered in the field -- is not null, *AND* it's different from what's in the database." I don't think this is correct. If the user changes the value of 'Fieldname' to $NULL$ from some other value, 'TR.Fieldname' != $NULL$ so the above qualification will actually fire. I think what I've heard before and understand to be true (although I most certainly may be wrong) is that 'Fieldname' != $NULL$ and 'TR.Fieldname' != $NULL$ are not the same thing, specifically in the case of a field being set to a NULL value. Michael A. McManus, SSgt, USAF Remedy Developer HQ 754 ELSG/DOMH DSN: 596-6478 / Comm: 334-416-6478 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Tim Widowfield Sent: Friday, February 22, 2008 1:08 PM To: [email protected] Subject: Re: Interview questions ** Wait, wait... This statement isn't right: "..the discussion isn't TR versus DB values, but rather whether or not there is a need to use the TR values (DB values are useful)." No, the point is in a filter qualification when you refer to a field name on the form, it is assumed by the AR Server engine that the value *is* the TR value. Hence, many people argue that adding the TR prefix merely adds fluff or noise. This qualification: ('TR.Fieldname' != 'DB.Fieldname') ...is identical to: ('Fieldname' != 'DB.Fieldname') To your first point, that you don't need the first half of: ( 'TR.Fieldname != $NULL$ ) AND ( 'Fieldname' != 'DB.Fieldname' ) ...be sure you understand what you really want the filter to do. What this is saying is, "I want the filter to fire if the transactional value -- i.e., what the user just entered in the field -- is not null, *AND* it's different from what's in the database." And you could write it like this: ( 'Fieldname != $NULL$ ) AND ( 'Fieldname' != 'DB.Fieldname' ) ...because field names without the TR prefix are presumed to be references to the current value in the form as the filter is executing. However, I've said it before -- I frequently will add the TR "fluff" if I think it helps readability. --Tim ----- Original Message ---- From: Thad K Esser <[EMAIL PROTECTED]> To: [email protected] Sent: Friday, February 22, 2008 12:52:17 PM Subject: Re: [ARSLIST] Interview questions ** "We settled on 'TR.Fieldname != $NULL$ AND 'Fieldname' != 'DB.Fieldname' What's wrong with this?" Its more complicated than it needs to be. ('Fieldname' != 'DB.Fieldname') by itself will give you the same results. By the way, the discussion isn't TR versus DB values, but rather whether or not there is a need to use the TR values (DB values are useful). My contention is that using TR values introduces unnecessary confusion and can cause unexpected results, without any benefit. I'll drop the topic for now, but if anyone wants to continue the discussion off-list feel free to email me. Thad Esser Remedy Developer "Argue for your limitations, and sure enough, they're yours."-- Richard Bach "Mike White" <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 02/22/2008 08:27 AM Please respond to [email protected] To [email protected] cc Subject Re: Interview questions ** Hello, Matt! This TR-vs-DB discussion usually gives me a headache that only a few beers can cure, but I'll weigh-in, anyway (proving that I can't learn from history!). Unless I misunderstood, Richard offered ( 'TR.lesson_status' = "Completed") as an alternative to ('DB.lesson_status' != "Completed" AND 'lesson_status' = "Completed") Good point about the db search, but I'd add the obvious - using only the TR value exposes the Filter to workflow updates. If another Filter pushes "Completed" to the record, even though it's already populated with "Completed", the Filter will fire. We settled on 'TR.Fieldname != $NULL$ AND 'Fieldname' != 'DB.Fieldname' What's wrong with this? And more to the point, what was wrong with David's original Run If: ( 'lesson_status' = "Completed" ) AND ( 'DB.lesson_status' != "Completed" ) I don't see where it would be a problem, either. ('Not sure I understood how API updates impact it). Mike White Office: 813-978-2192 E-mail: [EMAIL PROTECTED] Carey Matthew Black <[EMAIL PROTECTED]> Carey Matthew Black <[EMAIL PROTECTED]> Sent by: "Action Request System discussion list(ARSList)" <[email protected]> 02/22/2008 10:52 Please respond to arslist To: [email protected] cc: Subject: Re: Interview questions Actually... Run If qualifications (for Filters) do not cause "searches" to the DB. ( Which are the only context that the 'TR' vs 'DB' discussion makes any sense in.) Run If's (for Filters and Active Links) are evaluated by the ARS application (server or client) and not sent to the RDBMS. However, Escalations Run If's are sent to the RDBMS as well as Set/Push field qualifications. Yes.. Yes... if you reference 'Field' or 'DB.Field' in a Filter Run If then the record of interest for the transaction is fetched from the DB. But that is based on 'Entry ID' (Field 1) and is the unique clustered index on the form so that search is mute. It is the best that the DB can do and the value of having the DB values at had generally far out ways the cost of that trip to the RDMBS. (IMHO) -- Carey Matthew Black Remedy Skilled Professional (RSP) ARS = Action Request System(Remedy) Love, then teach Solution = People + Process + Tools Fast, Accurate, Cheap.... Pick two. On Fri, Feb 22, 2008 at 10:15 AM, McCabe, Richard A. (CMS/CTR) <[EMAIL PROTECTED]> wrote: > ** > > > > The following statements would fire the same, but the first statement would > be cleaner to read, and more efficient as it would not cause a full query of > the table by causing the database to run a "not equal to" search bypassing > your indexes. ( 'TR.lesson_status' = "Completed") vs. ('DB.lesson_status' != > "Completed" AND 'lesson_status' = "Completed") > > > > Richard McCabe > > > > > ________________________________ > > > From: Action Request System discussion list(ARSList) __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ ***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.*** __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" html___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
