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) <arslist@ARSLIST.ORG> To: arslist@ARSLIST.ORG <arslist@ARSLIST.ORG> Sent: Thu Oct 04 00:03:26 2007 Subject: Re: Filter Problem ** So does TR have any purpose? From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Joe D'Souza Sent: Wednesday, October 03, 2007 8:29 PM To: arslist@ARSLIST.ORG Subject: Re: Filter Problem ** I think neither runs any more queries than the other against the database. Comparison between the field and DB.field is the same as comparing TR.field to NULL with no more or less queries to the database.. Joe D'Souza -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] Behalf Of Jason Miller Sent: Wednesday, October 03, 2007 11:19 PM To: arslist@ARSLIST.ORG Subject: Re: Filter Problem While the TR is confusing isn't there a performance benefit? If I remember correctly a TR check will not run a query against the database (I haven't actually logged it to verify). Say you run a daily import of 500k employees (the requirement is to do it during the business hours for whatever reason) and are looking to see if their employment status has changed, if so create a request to take action. The import will perform an initial query the DB to find the existing record to update but then you have a filter that runs if 'EMP_Status' != 'DB.EMP_Status' (a required field). Wouldn't that cause an additional query on the database to retrieve the record you just retrieved? Using 'EMP_Status' != 'TR.EMP_Status' would check the server's memory if the value has changed and eliminate a redundant trip to the DB. In this case using a TR would eliminate 500k less queries to the database. During business hours that may be a huge savings (so I added the business hours part to help my example). Is my scenario correct? Jason -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Rabi Tripathi Sent: Wednesday, October 03, 2007 6:09 PM To: arslist@ARSLIST.ORG Subject: Re: Filter Problem Thad, I'm glad there's at least one person in the world who has settled on the same rule regarding use of TR values. Don't! Cause it's not necessary. There's no qualification you can't build without using TR. It's nothing but trouble. TR values tend to confuse people, as is evident from this thread. Even if you completely understand the nuances, there are many instances (many ways data can change) in which TR value will not be what you think. TR values give you what you expect only if the update is being done in Remedy user from a record that is "on display". If the update is being done from a dialog (common in ITSM 6), or if workflow is doing a query to get values and then pushing it back, use of TR values will drive you crazy. Why do you want to be driven crazy, I ask. There are enough opportunities to be driven crazy other ways. It has been around 5 years since I stopped using TR values. In with 'Field Name' != 'DB.Field Name' In with 'Field Name' != 'DB.Field Name' AND 'Field Name'!= $NULL$ Out with 'TR.Field Name' = $NULL$ (which misses blanking out of data anyway) --- 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 __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___
