Union joins are indeed another great example.. Done that too once before because the joins Remedy had were slow on Sybase, and a couple of them could be re-written as a union query, so what we had done (I know its against the books) is replaced the view in the database with the new view that had that union query. This had reduced the time the ARS took to query that view from something like a few minutes to a second or so..
It was on ITSP so creating a brand new view form would need a lot of modification in workflow so we chose that approach. We had to take care though everytime someone wanted to modify that join, because it would get overwritten so we had to have the db admin recreate that union query once any modification was done.. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arsl...@arslist.org]on Behalf Of Soria, Joe Sent: Wednesday, June 02, 2010 7:49 PM To: arslist@ARSLIST.ORG Subject: Re: ARERR 299 Too many levels in filter processing For our complex queries we sometimes create a database view and throw a view form on top. LJ LongWing <lj.longw...@gmail.com> wrote: 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:arsl...@arslist.org] On Behalf Of Joe D'Souza Sent: Wednesday, June 02, 2010 3:48 PM To: arslist@ARSLIST.ORG 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:arsl...@arslist.org]on Behalf Of Matt Worsdell Sent: Wednesday, June 02, 2010 5:43 AM To: arslist@ARSLIST.ORG 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"