Any chance you can coerce the specifics of the "known issue that can happen in certain circumstances"?
Axton Grams On Mon, Jul 7, 2008 at 5:56 PM, William Rentfrow <[EMAIL PROTECTED]> wrote: > 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: arslist@ARSLIST.ORG > 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: arslist@ARSLIST.ORG >> 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" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
