Misi, I know this is an extreme example....but one where using Remedy $LASTCOUNT$ was a HORRIBLE solution. I have a table on a form, the table has roughly 150,000 records in it. I need to do a SUM of the records in it for 3 separate columns. Doing this work via Filter and Remedy workflow, the way that Remedy did it was very simple. It took the 'Server Table Field Chunk Size' value on the Configuration tab of the server information dialog, which defaults to 1000 and performs a search on the db table the table field is based on saying 'select top 1000 ...', it finds that there are more than 1000 records, so it does it again for 'select top 2000 ...', it keeps incrementing the 'top' section by the chunk size till it finds a count that does not exceed the current chunk size. Each time it increases the number by chunk size, it of course takes longer for the query to return....in this example it needed to perform this recursive increase 150 times to get up to the 150K value....and it did this for each SUM I needed to do, which was 3...so to get the SUM of 3 columns in a table of 150K was taking about 10 min's. Converted it to select SUM() direct SQL setfields and it takes less than a second for all 3. This is a situation where deferred processing was not an option.
-----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Misi Mladoniczky Sent: Thursday, June 03, 2010 2: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"
