Then I would say that it's a question for BMC why they chose to architect it that way...:)
_____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: Monday, July 07, 2008 2:05 PM To: [email protected] Subject: Re: WUT GLE vs MT GLEWF in Modify People ** Yeah - the follow-up SQL call to the CTM:People form is the same in both APIs. _____ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of LJ Longwing Sent: Monday, July 07, 2008 2:58 PM To: [email protected] Subject: Re: WUT GLE vs MT GLEWF in Modify People ** 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,C2000000 06,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,C1000000 029,C1000000123,C1000000056,C108,C300469200,C1000000125,C1000000025,TO_CHAR( C301277100,'FM99999999999999999999999990.009'),C1000000023,C301277200,C26000 0001,C1000000052,C1000000906,C1000000050,C1000000121,C200000012,C1000000010, C301336500,C1000000039,C1000000060,C123,C1000000119,C1000000048,C1000000946, C3,C1000000846,C7,C1000000346,C1000000002,C1000000948,C1000000062,C100000000 4,C5,C112,C1000000042,TO_CHAR(C240000040V,'FM999999999999999990.00000000009' ),C240000040C,C240000040D,TO_CHAR(C240000040USD,'FM999999999999999990.000000 00009'),TO_CHAR(C240000040EUR,'FM999999999999999990.00000000009'),TO_CHAR(C2 40000040GBP,'FM999999999999999990.00000000009'),TO_CHAR(C240000040JPY,'FM999 999999999999990.00000000009'),C301349200,C1000000054,C1000000127,C302006500, C1000000654,C200000006,C1000000018,C1000000952,C1000000044,C1000000020,C110, C1000000046,C300495800,C160,C1000000026,C1000000049,C1000000122,C260141102,C 1000000028,C1000000034,C1000000036,C1000000126,C1000000541,C1000000032,C1000 000674,C1000000124,C1000000030,C1000000053,C301554200,C300469300,C600200100, C1000000949,C1000000024,TO_CHAR(C301554100,'FM99999999999999999999999990.009 '),C1000000926,TO_CHAR(C301554000,'FM99999999999999999999999990.009'),C24000 0042,C301600300,C1000000051,C1000000022,TO_CHAR(C301321200,'FM99999999999999 999999999990.009'),C1000000001,C1000000040,C179,C1000000074,C230000009,C1000 000069,C1000003975,C2,C1000000047,C1000000061,C1000000017,C1000000045,C30155 3900,C6,C1000000947,C4,C260000006,C1000000059,CO1000003962||';'||CC100000396 2||';'||C1000003962,C302006600,C1000000003,C200000007,C1000000021,C100000004 1,C1000000128,C1000002476,C1000000033,C8,C1000001262,C1000000043,C1000000120 ,C1000000037,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___ __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"
