I believe that gets appended to the SQL statement when then AL "Set fields" option of "if multiple records match use first matching request" is used.
-----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"
