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,C626,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"
