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___ 

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor: www.rmsportal.com ARSlist: "Where the Answers Are"

Reply via email to