Hi Gary, If it ever happens again I'll change:
'TR.Request Status' = "Completed" to 'Request Status' = "Completed" AND 'DB.Request Status' != "Completed" and see if that solves it. The larger issue is that if your filter fires if 'TR.field' = "VALUE", and workflow pushes "VALUE" to the field, the filter will fire. That's good to remember. Thanks! Dwayne ---- Original message ---- >Date: Mon, 24 Mar 2008 11:01:50 -0500 >From: "Opela, Gary L Contr OC-ALC/ITMA" <[EMAIL PROTECTED]> >Subject: Re: Runaway filter >To: [email protected] > >Hey Dwayne, I've run into problems similar to this before, and the >culprit was always TR. > >In my situation, I had Form A that would push a status to Form B. WF on >Form B said if TR.Status = Approved, then notify. Additionally, update >Form A. > >WF on Form A, said if TR.Field = <something, I cannot remember what>, >then push status of "Completed" to form B. > >Well, even if Form B was in status of Approved, any time you push a >value of Approved to that entry, then the TR.Status value is now >Approved. > >So, basically, Form A said if Field is in certain condition, let's say >Field C = "Bob" because I cannot remember what it was, then push >Approved to Form B. > >Filter on Form B said if TR.Status = Approved, then push Bob to Form A. > >Basically, it caused an infinite loop. > >The fix was to change 'TR.Status' = "Approved" to 'Status' = "Approved" >and 'DB.Status' != "Approved" to stop the loop. > >It only took about 2 yrs to track this down, as it only happened VERY >VERY rarely. > >Just bear in mind any time you only check the TR value of a field, you >can run into unexpected results. If the field is cleared out, then >TR.Field is $NULL$. If the field has a value pushed to it, say Approved, >and it's value is already Approved, then the TR.value of it is now >Approved, not $NULL$ as you would expect. This has bitten me more than >once. > >Thanks, > > >Gary Opela, Jr > >Sr. Remedy Developer > >RSP Certified > >Leader Communications, Inc. > >-----Original Message----- >From: Action Request System discussion list(ARSList) >[mailto:[EMAIL PROTECTED] On Behalf Of Dwayne Martin >Sent: Monday, March 24, 2008 10:45 AM >To: [email protected] >Subject: Re: Runaway filter > >Thanks, William, > >We did have the problem of duplicate emails before upgrading to 7.1, but >that was just two, or once in a great while, three copies. This is >about 100, followed by a core dump. > >Yes, we did rename "Status" to "Remedy Status" to keep it separate from >the other "Statuses". Maybe that has something to do with it. > >Dwayne > >---- Original message ---- >>Date: Mon, 24 Mar 2008 09:58:10 -0500 >>From: William Rentfrow <[EMAIL PROTECTED]> >>Subject: Re: Runaway filter >>To: [email protected] >> >>I'm not sure how you are setup to send messages - specifically how your >workflow is structured to email the person - but there was a bug in >earlier versions of 7.x (prior to 7.1) where users would occassionally >multiple copies of emails. This sounds like something similar. >> >>One thing to check though - did you rename the core "Status" field to >something else? You could be causing some internal workflow conflicts. >> >>William Rentfrow >>Principal Consultant, StrataCom >>[EMAIL PROTECTED] >>O 952-432-0227 >>C 701-306-6157 >> >>________________________________ >> >>From: Action Request System discussion list(ARSList) on behalf of >Dwayne Martin >>Sent: Mon 3/24/2008 9:36 AM >>To: [email protected] >>Subject: Runaway filter >> >> >> >>Hello Everyone, >> >>Here is a problem that you would expect on Halloween, not Easter. It >appeared on Friday, and now has disappeared. >> >>We have a "Request" form, with a filter that emails the assignee >whenever the "Status" changes to "Completed." ("Status" is a regular >char field, not the core Status.) We also have an "Authorization" >sub-file form which allows special people to authorize or reject the >request. >> >>On Friday it suddenly happened that whenever I created an >"Authorization" entry, or Authorized or Rejected an entry, the system >hung for about ten seconds, created a core dump, and churned about a >hundred AR System Email Messages entries to the assignee saying that the >Request had been closed. Fortunately "Send email" was set to "No" so >nobody got flooded with the emails. >> >>This happened in both our test and live ARS Systems, but it would >happen to some entries, not others. The ones it happened to seemed to >have no characteristics distinguishing them from those it didn't' happen >to. The filter runs if "TR.Status = "Completed." Some of the offending >entries were already "Completed," and some weren't. Creating >"Authorization" entries or Authorizing or Rejecting them shouldn't have >triggered the filter at all, let alone send it spinning into a cycle. >> >>There were no entries at all in the filter log, or any other error log. >> >>I came in early this morning to work on the problem, and behold! it has >vanished. I can't get it to happen. Our AR System re-starts every nite >so maybe that cured it. But problems that vanish mysteriously can also >reappear mysteriously. >> >>Any idea what to look for if this should happen again. >> >>(ARS 7.1 no patch, Oracle 10.2 db) >> >>Dwayne Martin >>James Madison University >> >>_______________________________________________________________________ >________ >>UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >>Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > >________________________________________________________________________ >_______ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > >_______________________________________________________________________________ >UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
