One problem with updating from LASTCOUNT would be that if you choose the escalation method, this update will happen only periodically.
The only way to keep it real time is to update it with every transaction. Then in this case you would need to update this count when a record is deleted or archived. It just may get a little more complicated than you bargained for.. I don't think it will be faster than count(*). I'm not sure how all databases handle count(*) but in the case of Oracle, I think value is derived from a fast full index scan of the on a indexed field.. The ARS has Field 1 as an indexed field even if no other custom index has been added. Maybe if someone has the time to do EXPLAIN and verify this, we could know the results.. I doubt other databases would be very different from this. Try a SHOW QUERY PLAN on MS-SQL or Sybase.. And the biggest advantage of using count(*) is you can design it such that, you use it only when needed. For e.g. a tab that holds this statistic, and a tab that is seldom used. And the calculation to happen only when the user gains focus to that tab.. or maybe even a dialog box on the press of a button that displays this information.. Joe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]]on Behalf Of Misi Mladoniczky Sent: Thursday, June 03, 2010 4: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"
