How about defaulting the Status field? I believe it would be acceptable to say that most of your queries are going to be for open records.
Another option (albeit expensive) would be to create a reporting server, so that way you wouldn't keep more records than you are willing to accept being table scanned. You could also just set the setting for blocking unqualified searches. It is simple enough to by-pass that setting, but it has to be a conscious effort. All they have to do is enter != $NULL$ in the ID field. Just a few ideas. HTH, Brian On Tue, Jul 22, 2008 at 2:06 PM, Kaiser Norm E CIV USAF 96 CS/SCCE < [EMAIL PROTECTED]> wrote: > Even though it's customizable by preference, it doesn't address the > issue of macros and ad hoc reports being possibly hosed...especially > because in this large, decentralized environment across a very large > area, it is not possible to know who does or will do ad hoc reporting. > > What I'm currently experimenting with is something somewhat crude...I've > added a radio button called "Quick Search" on the form in question. The > radio button is set to YES by default. When the value is set to YES (or > unselected) a search will only yield tickets opened in the past 90 days. > For users who want to do ad hoc reporting or pull up older tickets for > legacy purposes, they can just set the "Quick Search" to NO. > > Anyway, it works somewhat well but am hoping for other ideas for a > better solution. > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Rick Cook > Sent: Tuesday, July 22, 2008 2:56 PM > To: arslist@ARSLIST.ORG > Subject: Re: Unqualified Searches in Very Large Enterprises -- Thoughts, > Please > > ** > That's the beauty of using the preference values - they can be set > differently - and enforced - at the user and/or group level. That way, > you can leave the server value unlimited, but limit it dynamically at > the user level. > > Rick > > > On Tue, Jul 22, 2008 at 12:38 PM, Kaiser Norm E CIV USAF 96 CS/SCCE > <[EMAIL PROTECTED]> wrote: > > > Yes...but the "limit the number of requests returned" approach > has that > nasty tendency of messing up ad-hoc reports and macros, which > are done > extensively in this environment. > > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Axton > Sent: Tuesday, July 22, 2008 2:33 PM > To: arslist@ARSLIST.ORG > Subject: Re: Unqualified Searches in Very Large Enterprises -- > Thoughts, > Please > > Some things that come to mind: > - Force the use of a preference server, force the value of max > returned entries to 1000 or the likes > - Set a hard limit on the server for the max number of entries > returned from a get... > - Don't give users access to search regular forms (front-end > things > with display only forms) > > Axton Grams > > On Tue, Jul 22, 2008 at 3:25 PM, Kaiser Norm E CIV USAF 96 > CS/SCCE > <[EMAIL PROTECTED]> wrote: > > ** > > > > Hi everyone: > > > > > > > > I wanted to get everyone's take on this thorny issue...I know > this > matter has > > been discussed many times before, but I wanted to put a new > twist on > it. > > > > > > > > Specifically, I wanted to get anyone and everyone's thoughts > on the > problem > > of unqualified searches in a large enterprise. Specifically, > suppose > the > > following: Suppose you have a custom app being used in a very > large > > environment. Suppose in that environment you have established > a > ticket > > isolation system by setting hidden fields on the form on > SEARCH. > Tickets > > are isolated by every company within the enterprise. > > > > > > > > Now, each company has in excess of 150,000 tickets, and there > are 20 > > companies. The problem is, techs are accidentally clicking > the SEARCH > > button without any qualification...kicking off what is > *seemingly* an > > unqualified search. But the search is not truly unqualified > because > fields > > are getting set on SEARCH to effect the ticket isolation. But > the > problem > > remains - such a search goes out and attempts to fetch > 150,000+ > tickets. > > Several techs accidentally doing this at once (we have 800+ > techs, so > the > > possibility of techs doing this is pretty high) causes the > server to > slow > > way down. > > > > > > > > Thoughts on how to minimize this issue? Hopefully I've > described the > problem > > well enough. > > > > > > > > TIA, > > > > Norm > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the > Answers Are" > > html___ > > > ________________________________________________________________________ > _______ > 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" > > > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > > > _______________________________________________________________________________ > 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"
