I don't really think it makes sense to ever have a list of 32000 al. I am sure the query could be improved -- however a different approach would probably be the better route.
Meaning - I think some sort of namespace strategy should exist. Solution: you would walk a tree to get what you need. The root of the tree - would be server the first set of branches would be the list of forms on the server then under each form a list of: - filters, al, menus, etc... then under filters (the operations) -save, update, delete, merge, ... then under an operation (save) a list of filters by execution order, or criteria or by name or ??? (I know there is shared workflow -- and a strategy can be created to deal with that) But - excluding wanting to know "how many als exist on my server" - I can think of no reason to have a big list. (Another benefit of the tree approach above is a better naming result.) You can create a filter/al called 'require_first_name' which would be on your Person form. which is a better name than 'KDI_Person_save_or_modify_or_merge_require_first_name' (in my opinion) (The current admin strategy requires a solid naming strategy -- which I call "Grand Planning" -- and I think it is a bad strategy to require people "know a ton about the system" before they move forward) As - if you were a "beginner" -- you would need to develop for a year or two before you would see the benefits of a name strategy - therefore you won't do a strategy until it is too late) BLAH BLAH BLAH Another side benefit to the above tree approach is debugging. Generally when debugging I know the "action" that I want to follow (Like - saving the User form). So - I would like to click on User - click on filter - click on save - and get a list of the filters that may be related. (I am now looking at a manageable piece of the haystack) (And to continue my dream: -- then I would "right-click" the save on User form (in the tree) and say log activity criteria:$USER$ = "John Sundberg"... And then I would get a nice little filter log for save actions only on the User form for the user "John Sundberg". NICE NICE NICE - saves time - solves problems... To recap - changing the admin tool tree display can have significant positive results. -faster admin interaction to server -quicker to debugging problems -less rope to hang yourself -John On 7/31/07, Jarl Grøneng <[EMAIL PROTECTED]> wrote: > > Yes, we also facing huge problems with this. It takes time to process > 32000 ative links... > > Even if your forms in another application there is no problem adding > it to other application. Remember this is just temporary, when your > finish then you can remove your forms from the application you > created. > > -- > Jarl > > On 7/31/07, Axton <[EMAIL PROTECTED]> wrote: > > Thanks Jarl. This defect does seem to match what I documented. It's > > really unfortunate that my development has to slow down so drastically > > until they implement a fix, which was documented to be in the 2008 > > release. You would think that a bug that slows down every > > developer/administrator of their product would be pretty high on the > > list, seeing as one of the main advantage points of Remedy is the > > rapid turnaround for developing applications. > > > > Unfortunately, many of the forms I work against are already in > > applications, and getting into the habit of creating an application > > for things not typically in an application would be a bad practice. > > Even for large apps, like ITSM 7, using the existing application will > > not buy you much since so many objects are already in the application. > > > > Axton Grams > > > > On 7/30/07, Jarl Grøneng <[EMAIL PROTECTED]> wrote: > > > It is registred a defect on this: SW00268760. Classification: Under > > > Consideration > > > > > > An workaround is to create an application, move the forms your working > > > on into this application. Then it is faster to work in the admin tool. > > > > (you have to manually refresh the active link list to reflect your > > > changes) > > > > > > -- > > > Jarl > > > > > > On 7/30/07, Axton < [EMAIL PROTECTED]> wrote: > > > > Would someone mind proofreading this before I send it to BMC? > > > > > > > > http://bugs.arswiki.org/show_bug.cgi?id=58 > > > > > > > > It has to do with the performance of the admin tool and contains > some > > > > suggestions to alleviate the resource requirements of some expensive > > > > operations. > > > > > > > > Thanks, > > > > Axton Grams > > > > > > > > > _______________________________________________________________________________ > > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where > > > > the Answers Are" > > > > > > > > > > > _______________________________________________________________________________ > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.orgARSlist:"Where > > > the Answers Are" > > > > > > > > _______________________________________________________________________________ > > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > > > > _______________________________________________________________________________ > > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where > the Answers Are" > -- John David Sundberg 235 East 6th Street, Suite 400B St. Paul, MN 55101 (651) 556-0930-work (651) 247-6766-cell (651) 695-8577-fax [EMAIL PROTECTED] _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
