Hi Joe, As you can see in the log where only TR-values was used, the server does the following when updating the records: UPDATE T130 SET C610000003='TR',C5='miz',C6=1191493444 WHERE C1 = '000000000000001' AND ((C6 <= 1191493441) OR (C5 = 'miz'))
It apparently appends my original Modify-Date to the update, and handles the situation where someone else has beaten me to the database. As you see, the only value updated, ar the field I changed, i.e. C610000003. Here is the log that shows this: http://www.rrr.se/tmp/TestAssignedToTR.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. > That's what I thought that it should perform a fetch for DB values too. > The > DB value could be changed by another user after the initial fetch of the > record, hence what displays on the client tool after the initial fetch of > the record, may not represent the true DB value. > > I wonder though what would happen if lets say the value of a field is > "XYZ". > User 1 opens the record.. > > At about the same time User 2 opens the same record, and changes the value > of "XYZ" to "abc" and performs the save. > > User 1 then changes what he sees on his screen "XYZ" to "abc". Considering > that the DB value now is already "abc" due to the change done earlier by > User 2, would the TR value now be NULL? Or would it be "abc"? > >>From your conclusion based on the SQL logs that TR doesn't perform a >> fetch, > the system would not know that the value has changed. Isn't that a flaw in > the design? > > Joe D'Souza > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] Behalf Of Misi Mladoniczky > Sent: Thursday, October 04, 2007 6:31 AM > To: arslist@ARSLIST.ORG > Subject: Re: Filter Problem > > > Hi, > > You are correct in the assumption that TR-values can save a little bit on > performance. > > The server looks through the run-if-qualification of all filters. > > If anywhere there is a 'Field' or 'DB.Field', the server will need fetch > these values from the database. And the values of all other fields of the > form as well! > > If you only have 'TR.Field', static values or keywords. This fetch is not > needed. > > Note that my test form has a lot of fields, and only two filters. One is > disabled and one is enabled in the samples below: > > ('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 > > All fields will be fetched as soon as you have one 'Field' or 'DB.Field' > in > your filters, so adding fields will do nothing to performance. > > I have noticed this behaviour in previous versions. The verion I am > testing > is version 7.0.1 patch 003. > > I think that the TR-values can have a legitimate use sometimes. Either for > the reason of performance, or the reason of simplifying your run-ifs: > > Example 1: ('TR.CustID' != $NULL$) > Your filter makes sure that the CustName is in sync with your CustID. It > does not matter much if this filter sometimes run when it is not really > neccessary. > > Example 2: ('TR.Assigned To' != $NULL$ AND 'TR.Assigned To' != $USER$) > Your filter sends a notification to the assigned person. If the field has > not really been changed, an extra notification is sent, but does no real > damage. > > Example 3: ('TR.Status' != $NULL$) > Your filter controls something or other connected with the status. Extra > controls may happen, but does not affect things much. > > 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. > >> 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 >>> >>> >>> >>> "Mayfield, Andy L." <[EMAIL PROTECTED]> >>> Sent by: "Action Request System discussion >>> list(ARSList)" >>> <arslist@ARSLIST.ORG> >>> 10/03/2007 07:55 AM >>> Please respond to >>> arslist@ARSLIST.ORG >>> >>> >>> To >>> arslist@ARSLIST.ORG >>> cc >>> >>> Subject >>> Re: Filter Problem >>> >>> >>> >>> >>> >>> >>> OK, I think after a few cups of coffee I am now able >>> to comprehend this. >>> >>> TR.Field != $NULL$ should fire anytime the field is >>> changed, unless it >>> is actually set to NULL. >>> >>> That is rather confusing to simple minded folk such >>> as myself (-: >>> >>> Andy L. Mayfield >>> Sr. System Operation Specialist >>> Alabama Power Company >>> Office: 8-226-1805 >>> >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) >>> [mailto:[EMAIL PROTECTED] On Behalf Of Shellman, >>> David >>> Sent: Wednesday, October 03, 2007 9:16 AM >>> To: arslist@ARSLIST.ORG >>> Subject: Re: Filter Problem >>> >>> Andy, >>> >>> As Axton said TR.field really is the value of the >>> transaction. >>> >>> If a field doesn't change then the TR.field is null. >>> There isn't a >>> transaction because the DB.field and field are the >>> same. >>> >>> If a field changes TR.field evaluates to what was >>> just entered. So if >>> you change a field from Hello World to Good Morning, >>> TR.field will >>> evaluate to Good Morning, DB.field evaluates to >>> Hello World, and the >>> field evaluates to Good Morning. >>> >>> The tricky one is where the field was Hello World >>> but is now set to >>> NULL. The DB.field is Hello World and the field >>> value is NULL. Because >>> there is a change there is a transaction but the >>> TR.field evaluates to >>> NULL because the field is actually set to NULL. >>> >>> Dave >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) >>> [mailto:[EMAIL PROTECTED] On Behalf Of Mayfield, >>> Andy L. >>> Sent: Wednesday, October 03, 2007 10:06 AM >>> To: arslist@ARSLIST.ORG >>> Subject: Re: Filter Problem >>> >>> I thought everyone was saying that if I set a field >>> to NULL (that >>> previously had a value), the TR value would NOT be >>> NULL? >>> >>> I am getting confused. I may need to take a break >>> for coffee and a >>> cigarette to clear my head (-: >>> >>> >Andy L. Mayfield >>> Sr. System Operation Specialist >>> >Alabama Power Company >>> Office: 8-226-1805 >>> >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) >>> [mailto:[EMAIL PROTECTED] On Behalf Of Axton >>> Sent: Wednesday, October 03, 2007 8:41 AM >>> To: arslist@ARSLIST.ORG >>> Subject: Re: Filter Problem >>> >>> This one that probably often trips people up; if you >>> set the field to >>> null, the TR value will be null. >>> >>> The TR value represent the current transactions >>> value, if no change >>> occurred in the transaction, then the TR value is >>> null >>> >>> The DB value represents what was last committed to >>> the database; prior >>> to the current transaction >>> >>> The value represents the current value, regardless >>> of the TR or DB >>> values >>> >>> Axton Grams >>> >>> On 10/3/07, Mayfield, Andy L. >>> <[EMAIL PROTECTED]> wrote: >>> > ** >>> > >>> > >>> > >>> > OK, I thought I had this figured. So if while >>> modifying a ticket, you >>> > change a field that previously had a value, to >>> NULL (blank) then the >>> TR >>> > value is NOT NULL. >>> > >>> > >>> > >>> > I need more coffee. >>> > >>> > >>> > >>> > >>> > Andy L. Mayfield >>> > Sr. System Operation Specialist >>> > Alabama Power Company >>> > Office: 8-226-1805 >>> > >>> > ________________________________ >>> > >>> > >>> > From: Action Request System discussion >>> list(ARSList) >>> > [mailto:[EMAIL PROTECTED] On Behalf Of Joe >>> D'Souza >>> > Sent: Tuesday, October 02, 2007 10:57 PM >>> > >>> > To: arslist@ARSLIST.ORG >>> > Subject: Re: Filter Problem >>> > >>> > >>> > >>> > >>> > >>> > Yes the TR value is NULL if there is no >>> modification even if there is >>> a DB >>> > value to that field.. >>> > >>> > >>> > >>> > >>> > >>> > This is how it works.. when you are submitting a >>> new record, and if >>> there is >>> > a value in the field, then the TR value is not >>> NULL (obviously). The >>> DB >>> >> === message truncated === > > _______________________________________________________________________________ > 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"
