I have been informed that this is a known issue that can happen in certain circumstances. The plan is to address this in later releases with some further optimization to get rid of the occasional double queries that can happen during a API call within set fields actions, etc.
Vague enough? :) In short I broke the OOB workflow down into parts, removed the "OR" from the queries, and although the mid-tier is still doing a GLEWF call it is avoiding a table scan and is faster. -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Axton Sent: Monday, July 07, 2008 3:24 PM To: [email protected] Subject: Re: WUT GLE vs MT GLEWF in Modify People "WHERE ROWNUM <= 2", why would it only return the first 2 or 3 rows on the web and not the user tool? Axton Grams On Mon, Jul 7, 2008 at 3:58 PM, LJ Longwing <[EMAIL PROTECTED]> wrote: > ** > My first thought was that the mid-tier does a with fields in order to > reduce the subsequent calls to the DB...but looking at the call that > mid-tier is using...it's doing quite a bit more than that...it appears > to be pulling currency fields, doing an outer join on the B > table....does the subsequent sql call from both the client and the web > look the same as the initial from the web? > ________________________________ > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow > Sent: Monday, July 07, 2008 1:27 PM > To: [email protected] > Subject: WUT GLE vs MT GLEWF in Modify People > > ** > In IM 7.03 patch 7 we have users who are experiencing slow-downs when > accessing some base product functionality. > > The two scenarios are: > > Windows User Tool: > The user opens an existing Incident and presses the "Modify" button on > the customer tab to bring up the Customer Record. The screen opens > quickly and displays the customer record. API/SQL logging indicates a > +/- GLE is being issued which completes very quickly. A further > action later on retries the actual values for the record to display. > > Mid-tier (solaris + IBM HTTP Server + Websphere) standalone - 7.1 > patch 001 The user opens an existing Incident and presses the "Modify" > button on the customer tab to bring up the Customer Record. The > screen opens immediately to the "Loading" screen takes 45 seconds or > so to display the customer record. API/SQL logging indicates a +/- > GLEWF is being issued which completes very slowly. A further action > later on retries the actual values for the record to display. This goes quickly as in the first case. > > Why on earth would the same workflow cause a GLE in the WUT and GLEWF in the > mid-tier? It's the exact same workflow that is firing - there is no custom > anything based on the client type. > > Also - the SQL commands that are issued by these GLE/GLEWF sequences > is wildly different. > > GLE SQL: > SELECT > T659.C1,C1000000018,C1000000019,C1000000056,C1000000001,C1000000010,C2 > 00000006,C200000012,C260000001,C7 FROM T659 WHERE ((T659.C1 = > 'PPL000000923440') OR (T659.C4 = ' ')) ORDER BY > 2 ASC,3 ASC, 1 ASC > > GLEWF SQL: > > SELECT > T659.C1,C1000000188,C1000000027,C1000000031,C1000000035,C1000000673,C1 > 000000029,C1000000123,C1000000056,C108,C300469200,C1000000125,C1000000 > 025,TO_CHAR(C301277100,'FM99999999999999999999999990.009'),C1000000023 > ,C301277200,C260000001,C1000000052,C1000000906,C1000000050,C1000000121 > ,C200000012,C1000000010,C301336500,C1000000039,C1000000060,C123,C10000 > 00119,C1000000048,C1000000946,C3,C1000000846,C7,C1000000346,C100000000 > 2,C1000000948,C1000000062,C1000000004,C5,C112,C1000000042,TO_CHAR(C240 > 000040V,'FM999999999999999990.00000000009'),C240000040C,C240000040D,TO > _CHAR(C240000040USD,'FM999999999999999990.00000000009'),TO_CHAR(C24000 > 0040EUR,'FM999999999999999990.00000000009'),TO_CHAR(C240000040GBP,'FM9 > 99999999999999990.00000000009'),TO_CHAR(C240000040JPY,'FM9999999999999 > 99990.00000000009'),C301349200,C1000000054,C1000000127,C302006500,C100 > 0000654,C200000006,C1000000018,C1000000952,C1000000044,C1000000020,C11 > 0,C1000000046,C300495800,C160,C1000000026,C1000000049,C1000000122,C260 > 141102,C1000000028,C1000000034,C1000000036,C1000000126,C1000000541,C10 > 00000032,C1000000674,C1000000124,C1000000030,C1000000053,C301554200,C3 > 00469300,C600200100,C1000000949,C1000000024,TO_CHAR(C301554100,'FM9999 > 9999999999999999999990.009'),C1000000926,TO_CHAR(C301554000,'FM9999999 > 9999999999999999990.009'),C240000042,C301600300,C1000000051,C100000002 > 2,TO_CHAR(C301321200,'FM99999999999999999999999990.009'),C1000000001,C > 1000000040,C179,C1000000074,C230000009,C1000000069,C1000003975,C2,C100 > 0000047,C1000000061,C1000000017,C1000000045,C301553900,C6,C1000000947, > C4,C260000006,C1000000059,CO1000003962||';'||CC1000003962||';'||C10000 > 03962,C302006600,C1000000003,C200000007,C1000000021,C1000000041,C10000 > 00128,C1000002476,C1000000033,C8,C1000001262,C1000000043,C1000000120,C > 1000000037,C1000000019,C109 FROM T659 LEFT OUTER JOIN B659 ON > (T659.C1 = B659.C1) WHERE ((T659.C1 = > 'PPL000000923440') OR (T659.C4 = ' ')) ORDER BY 55 ASC,122 ASC, 1 ASC > ) WHERE ROWNUM <= 2 > > William Rentfrow, Principal Consultant [EMAIL PROTECTED] C > 701-306-6157 O 952-432-0227 > > __Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are" > html___ > __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"
