As long as they don't implement it like they did the details of the object list. The method they took to implement this is horribly inefficient and is the reason why it takes so long to save an active link:
http://bugs.arswiki.org/show_bug.cgi?id=58 I would like to see this fixed, which is a result of the poorly implemented object list details feature of the admin tool. If any additional features are added that use sql to pull additional information that can not be easily represented through the native api calls, I would certainly hope that this is not the model implementation. Axton Grams On 8/15/07, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > Rick, > > I hear you. So maybe this will be of some help. Here is a sample of > some SQL snips that I use to "workaround" the guide stuff. (Warning, > written for SYBASE... YMMV, but you can get the idea.) > > A) Find a filter that calls a specific Filter Guide: > > select f.name, c.guideName from filter_call c, filter f where > c.guideName = '<filterGuideName>' and c.filterId = f.filterId > > B) List all containers (and show a reasonable english string for the > type of container) that contain a specific Filter > > select a.name, (CASE WHEN a.containerType = 1 THEN "ALGuide" ELSE > (CASE WHEN a.containerType = 2 THEN "Application" ELSE (CASE WHEN > a.containerType = 3 THEN "PackingList" ELSE (CASE WHEN a.containerType > = 4 THEN "FLGuide" ELSE (CASE WHEN a.containerType = 5 THEN > "WebService" ELSE convert(char(5), a.containerType) END) END) END) > END) END) AS container_str from arcontainer a, arreference b, filter f > where a.containerId = b.containerId and f.filterId = b.referenceObjId > and b.dataType = 0 and b.referenceType=3 and f.name = '<filterName>' > order by a.containerType, a.name > > > The same kind of thing can be done Active Links and such too. But I > will leave those details for later. > > > But the fact that this kind of SQL can be executed very quickly by the > RDBMS suggests to me that with very little work BMC could do this same > SQL calls and add a few items to the "Related Workflow" items with no > changes to the AR System meta data at all. ( or with a few changes to > the meta data then the SQL could be much simpler too.) > > > > And I am a bit more optimistic that the cost of the real time > relationships than you are too. Even if it is "costly" on a > development server I think the benefits would far out way the costs. > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > > On 8/15/07, Rick Cook <[EMAIL PROTECTED]> wrote: > > Nice list, Matt. I would add one more to the third one - how about a tab in > > each workflow object that shows every container in which it resides? It > > would be nice to see whether an Active Link I'm looking at runs in a Guide, > > since there's no obvious marking (apart from clues like no firing condition) > > on those presently. And even if I know or suspect that an AL is in a Guide, > > it's a pain to figure out which one it's in. > > > > And on the Related Objects stuff - while I share your desire to keep it real > > time, without some restructured storage mechanisms for that data, the > > performance impact would make it not worth it. > > > > Rick > > _______________________________________________________________________________ > 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"
