Hmmmmm......I think what you are saying is right....lemme get more into it and do some more tests.... Will keep the list posted.
Ankur -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: 06 February 2007 03:15 PM To: [email protected] Subject: Re: Difference in execution of Application-Bus-Time-Diff Hi again, I did miss one more or less inconsequential thing... The dates differed on the "working" call, and the time span was "2007-02-02 09:41:51" to "2007-02-06 07:01:12". The "Gold - Critical" apparently is active for 24 hours a day. Best Regards - Misi, RRR AB, http://www.rrr.se > Hi Ankur, > > The Bus-Time-Form-Data is recached periodically. This is why it > sometimes does more SQL-calls. > > I would guess that the "Silver - Major" does not span the time > specified in the first call. > > I think you are in the same timezone as I. My guess is that "Silver - > Major" probably starts at 8:00 or so, and that "Gold - Critical" is > active during the span specified. > > The "failing" call spans from 2007-02-06 07:05:00 to 07:06:26. > The working call spans from 2007-02-06 07:01:12 to 09:41:51. > > Best Regards - Misi, RRR AB, http://www.rrr.se > >> Hi All, >> >> I suddenly got into a spooky situation when everything works fine and >> suddenly next day you retry and things starts to act weird. >> >> There's a filter which when passed sets a field and here's the SQL >> and FLTR log excerpt for the same. >> >> This is for the ticket coming in through mail >> >>> 0: Set Fields >>> /* Tue Feb 06 2007 07:06:28.0521 */SELECT >> C536870931,C1404050501,C1404051002,C1404051001 FROM T116 WHERE C1 >> '000000000000093' >>> /* Tue Feb 06 2007 07:06:28.0547 */COMMIT WORK >>> Application-Bus-Time-Diff "1170741900" "1170741986" >> "Silver - Major" "Silver - Major" >>> Exit code: 0 Value: 0 >>> Temp_Restoration_Time (1404051404) = 0 >> >> till 3 days back this would calculate the exact difference and now it >> only gives me 0. Nothing changed in these few days. >> >> Now the scary part is, when this same filter acts and pass the >> qualification for another ticket, it calculates the right business >> time difference and also the log shows more SQL commands: >> >> >> >> > 0: Set Fields >>> /* Tue Feb 06 2007 07:01:15.0537 */SELECT >> C536870931,C1404050501,C1404051002,C1404051001 FROM T116 WHERE C1 >> '000000000000089' >>> /* Tue Feb 06 2007 07:01:15.0574 */COMMIT WORK >>> /* Tue Feb 06 2007 07:01:15.0595 */SELECT T80.C1,C8 FROM T80 WHERE >> (T80.C8 = 'Gold - Critical') ORDER BY 1 ASC >>> /* Tue Feb 06 2007 07:01:15.0632 */COMMIT WORK >>> /* Tue Feb 06 2007 07:01:15.0656 */SELECT C600 FROM T80 WHERE C1 >>> '000000000000016' >>> /* Tue Feb 06 2007 07:01:15.0682 */COMMIT WORK >>> /* Tue Feb 06 2007 07:01:15.0702 */SELECT T153.C1,C8 FROM T153 WHERE >> (T153.C8 = 'Gold - Critical') ORDER BY 1 ASC >>> /* Tue Feb 06 2007 07:01:15.0729 */COMMIT WORK >>> /* Tue Feb 06 2007 07:01:15.0749 */SELECT >> C1,C2,C3,C4,C5,C6,C7,C8,0,C180,C181,C620,C621,C622,C623,C624,C625,C62 >> 6,C >> 630,C631,C632,C633,C634,C635,C636,C1201032721,C1201032802,C1402031913 >> ,C2 >> 005101201 FROM T153 WHERE C1 = '000000000000027' >>> /* Tue Feb 06 2007 07:01:15.0777 */SELECT entryId,T0,U0,T1,U1,T2,U2 >> FROM H153 WHERE entryId = '000000000000027' >>> /* Tue Feb 06 2007 07:01:15.0799 */COMMIT WORK >>> Application-Bus-Time-Diff "1170405711" "1170741672" >> "Gold - Critical" "Gold - Critical" >>> Exit code: 0 Value: 335961 >>> Temp_Restoration_Time (1404051404) = 335961 >> >> there is NO SET FIELD IF condition >> why it is calculating 0 in the first case? and Why is the difference >> between the number of SQL calls? >> >> Regards >> Ankur >> >> _____________________________________________________________________ >> __________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> ARSlist:"Where the Answers Are" >> > > > ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are" _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers Are"
