Yep - same view - it's the exact same workflow firing in both cases doing a standard window open in dialog form and using the same view. There's no differentiation in the code for client type, etc.
________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Grooms, Frederick W Sent: Monday, July 07, 2008 3:18 PM To: arslist@ARSLIST.ORG Subject: Re: WUT GLE vs MT GLEWF in Modify People ** I haven't seen the canned apps in a while but, are WUT and the Mid-Tier pulling up the same view? Based on the logs it would seem that the web has a couple of fields on it's view that are not on the Windows view. Fred ________________________________ From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of William Rentfrow Sent: Monday, July 07, 2008 3:05 PM To: arslist@ARSLIST.ORG 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: arslist@ARSLIST.ORG 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: 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,C200 000006,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,C100 0000029,C1000000123,C1000000056,C108,C300469200,C1000000125,C1000000025, TO_CHAR(C301277100,'FM99999999999999999999999990.009'),C1000000023,C3012 77200,C260000001,C1000000052,C1000000906,C1000000050,C1000000121,C200000 012,C1000000010,C301336500,C1000000039,C1000000060,C123,C1000000119,C100 0000048,C1000000946,C3,C1000000846,C7,C1000000346,C1000000002,C100000094 8,C1000000062,C1000000004,C5,C112,C1000000042,TO_CHAR(C240000040V,'FM999 999999999999990.00000000009'),C240000040C,C240000040D,TO_CHAR(C240000040 USD,'FM999999999999999990.00000000009'),TO_CHAR(C240000040EUR,'FM9999999 99999999990.00000000009'),TO_CHAR(C240000040GBP,'FM999999999999999990.00 000000009'),TO_CHAR(C240000040JPY,'FM999999999999999990.00000000009'),C3 01349200,C1000000054,C1000000127,C302006500,C1000000654,C200000006,C1000 000018,C1000000952,C1000000044,C1000000020,C110,C1000000046,C300495800,C 160,C1000000026,C1000000049,C1000000122,C260141102,C1000000028,C10000000 34,C1000000036,C1000000126,C1000000541,C1000000032,C1000000674,C10000001 24,C1000000030,C1000000053,C301554200,C300469300,C600200100,C1000000949, C1000000024,TO_CHAR(C301554100,'FM99999999999999999999999990.009'),C1000 000926,TO_CHAR(C301554000,'FM99999999999999999999999990.009'),C240000042 ,C301600300,C1000000051,C1000000022,TO_CHAR(C301321200,'FM99999999999999 999999999990.009'),C1000000001,C1000000040,C179,C1000000074,C230000009,C 1000000069,C1000003975,C2,C1000000047,C1000000061,C1000000017,C100000004 5,C301553900,C6,C1000000947,C4,C260000006,C1000000059,CO1000003962||';'| |CC1000003962||';'||C1000003962,C302006600,C1000000003,C200000007,C10000 00021,C1000000041,C1000000128,C1000002476,C1000000033,C8,C1000001262,C10 00000043,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___ _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"
