There are times where the OOB box of a Remedy app can't be made to work with workflow.
For example - in IM 7.03 - the "Transfers between groups/individuals" # is wrong out of the box. Most people do not notice it because the number that is displayed on the screen in an Incident is right - but what is actually stored is wrong. The count would be updated when the Incident was opened and the change flag was reset. Our local rules dictate that any base product issues get kicked up to BMC tech support first. They actually could not find a workflow solution to this given the way the app was built. They registered a defect. I fixed it just using a direct SQL call. The other choice was ripping out a bunch of base product workflow and re-writing custom code. I haven't checked to see if this was fixed in 7.5. Anyone play with that? William Rentfrow Principal Consultant, StrataCom Inc. [email protected] Blog: www.williamrentfrow.com O 715-592-5185 C 715-410-8056 -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Misi Mladoniczky Sent: Thursday, June 03, 2010 3:45 AM To: [email protected] Subject: Re: ARERR 299 Too many levels in filter processing Hi, Unions are not possible as such, but it is not hard, and quite robust, to create filters that sync the relevant data from various forms into another form, which will then have the same data as the union would have. Instead of count(*), you can create counter-records in a counter-forms that are updated by filters. Possibly with a slow safe-guard count of records done by escalations each night. It can use $LASTCOUNT$ instead of direct SQL. The end result may be even faster than the count(*) direct SQL :-) 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. Find these products, and many free tools and utilities, at http://rrr.se. > Another situation is query unions....we have several locations in our > app where we need to union several searches together into a single > resultset, not possible within the Remedy architecture. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of Joe D'Souza > Sent: Wednesday, June 02, 2010 3:48 PM > To: [email protected] > Subject: Re: ARERR 299 Too many levels in filter processing > > To do what you need to do when all else fails or if it is impossible > to do it directly.. > > I once had the requirement in a multi tenant environment (Submitter > mode > locked) to change the contents of field 2.. Only and admin user was to > have the permissions to change that. How would you be able to do it > from within the ARS if the workflow didn't run a Direct SQL? > > Other times I use it is when I'm dead sure using it would save time > and that chances are bleak that the syntax would ever change.. Simple > update or set statements that are hardly likely to change in syntax on > that database or if you move across from databases are fine to use.. > > Counting records in a table is another example where I'd rather use a > Direct SQL than the ARS as it would be way faster.. And what are the > chances that the count(*) function would ever change when used in a > select statement? > > So there are exceptions such as that where some things are just not > possible without resorting to Direct SQL. It is like a 911 call.. Just > because you have that option you do not call it for recreational > purposes.. > > Joe > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]]on Behalf Of Matt Worsdell > Sent: Wednesday, June 02, 2010 5:43 AM > To: [email protected] > Subject: Re: ARERR 299 Too many levels in filter processing > > > I fail to see why, Direct SQL is a legitimate built in option. > > >> Hi, >> >> Direct SQL makes a system hard to manage. If there are built in >> options other than Direct SQL, use them instead! >> >> 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. >> Find these products, and many free tools and utilities, at >> http://rrr.se. >> >>> Another option would be to use a Direct SQL Action. >>> >>> Matt >>> >>> >>>> Hi fellow listers, >>>> >>>> This is something which i had tried. >>>> >>>> My need was to change a field value in a form after a record is >>>> submitted/modified and the record for which i need the field value >>>> change to be made is the one which got submitted/modified. >>>> >>>> So I created a filter which gets triggerred(i.e on action Submit >>>> and Modify)and then do a push field and change the value in the >>>> field for the same form-record. >>>> >>>> Now my problem here is that as I am doing the push in the same form >>>> for changing a value in the field, "ARERR 299 Too many levels in >>>> filter processing" occurs. I know this happens because the Push >>>> field action ultimately triggers a submit/modify action on the same >>>> form and the filter get triggerred infinitely. >>>> >>>> Can anyone suggest me a different approach to this? >>>> >>>> Cheers :) > > ______________________________________________________________________ > ______ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend > wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" > > ______________________________________________________________________ > _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" > > -- > This message was scanned by ESVA and is believed to be clean. > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
