A flaw, maybe. The solutions I see to address this would be some type of record locking to prevent updates based on stale data. I guess there could be a couple of approaches to this: - return an error if you attempt to update and the data you are using for the update is stale - disallow the retrieval of records for update if someone else has a lock - return a note that the record was updated by another user
One has to weigh the consequences of implementing something to address this behavior against the consequences of not implementing something to address it. The third, obviously, is what is currently implemented. I have to correct myself on one item. It appears Misi was right that the entire record is fetched during each ARSetEntry call. Ah well, something changed when I wasn't looking. Axton Grams On 10/4/07, Joe D'Souza <[EMAIL PROTECTED]> wrote: > ** > > 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 === > __20060125_______________________This posting was > submitted with HTML in it___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
