I am new to splunk, and trying to understand what’s the difference between dispatch.earliest_time = "-15m#m" and dispatch.earliest_time = "-15m”. Thanks!
There is no practical difference. Both begin the search 15 minutes before the current time. The #m portion rounds off the start time to beginning of the minute, but is not necessary since the search scheduler uses minute resolution.
In Automation Anywhere, the minute system variable ($Minute$) will only return 1 digit if minutes is less than 10. The variable manager doesn't allow for the format to be edited.
Can you please suggest any workarounds? Thanks!
Create a variable and name it $vMinute$.
Using if condition check if the day is less than 10, then add 0 to the left using variable operation.
The same approach can be done for the hour variable as well.
I'm trying to show rows which have hour value (24H format) after current time.
Currently I'm using:
where time(hour)>time(now())
but this comparision fails when current time is for example 23:50 and stored value is 00:10.
Is there any way to copmare it correctly?
This is the part of query to show nearest departures of buses on bus stop.
Well, you could try:
where time(hour)>time(now()) or time(hour) = 0
I think it would be better if you check if it's in future first, and then check the difference. As far as I understand, that would works better for your usage:
WHERE time > NOW() and TIMESTAMPDIFF(MINUTE,time,NOW()) < 60
I am attempting to retrieve a resources work hours to perform some logic I require. I understand that the CRM scheduling engine is a little clunky around such things, but I assumed that I would be able to find out how the working hours were stored in the DB eventually...
So a resource has associated calendars and those calendars have associated calendar rules and inner calendars etc. It is possible to look at the start/end and frequency of aforementioned calendar rules and query their codes to work out whether a resource is 'working' during a given period. However, I have not been able to find the actual working hours, the 9-5 shall we say in any field in the DB.
I even tried some SQL profiling while I was creating a new schedule for a resource via the UI, but the results don't show any work hours passing to SQL. For those with the patience the intercepted SQL statement is below:-
EXEC Sp_executesql
N'update [CalendarRuleBase] set [ModifiedBy]=#ModifiedBy0, [EffectiveIntervalEnd]=#EffectiveIntervalEnd0, [Description]=#Description0, [ModifiedOn]=#ModifiedOn0, [GroupDesignator]=#GroupDesignator0, [IsSelected]=#IsSelected0, [InnerCalendarId]=#InnerCalendarId0, [TimeZoneCode]=#TimeZoneCode0, [CalendarId]=#CalendarId0, [IsVaried]=#IsVaried0, [Rank]=#Rank0, [ModifiedOnBehalfBy]=NULL, [Duration]=#Duration0, [StartTime]=#StartTime0, [Pattern]=#Pattern0 where ([CalendarRuleId] = #CalendarRuleId0)',
N'#ModifiedBy0 uniqueidentifier,#EffectiveIntervalEnd0 datetime,#Description0 ntext,#ModifiedOn0 datetime,#GroupDesignator0 ntext,#IsSelected0 bit,#InnerCalendarId0 uniqueidentifier,#TimeZoneCode0 int,#CalendarId0 uniqueidentifier,#IsVaried0 bit,#Rank0 int,#Duration0 int,#StartTime0 datetime,#Pattern0 ntext,#CalendarRuleId0 uniqueidentifier',
#ModifiedBy0='EB04662A-5B38-E111-9889-00155D79A113',
#EffectiveIntervalEnd0='2012-01-13 00:00:00',
#Description0=N'Weekly Single Rule',
#ModifiedOn0='2012-03-12 16:02:08',
#GroupDesignator0=N'FC5769FC-4DE9-445d-8F4E-6E9869E60857',
#IsSelected0=1,
#InnerCalendarId0='3C806E79-7A49-4E8D-B97E-5ED26700EB14',
#TimeZoneCode0=85,
#CalendarId0='E48B1ABF-329F-425F-85DA-3FFCBB77F885',
#IsVaried0=0,
#Rank0=2,
#Duration0=1440,
#StartTime0='2000-01-01 00:00:00',
#Pattern0=N'FREQ=WEEKLY;INTERVAL=1;BYDAY=SU,MO,TU,WE,TH,FR,SA',
#CalendarRuleId0='0A00DFCF-7D0A-4EE3-91B3-DADFCC33781D'
The key parts in the statement are the setting of the pattern:-
#Pattern0=N'FREQ=WEEKLY;INTERVAL=1;BYDAY=SU,MO,TU,WE,TH,FR,SA'
However, as mentioned, no indication of the work hours set.
Am I thinking about this incorrectly or is CRM doing something interesting around these work hours?
Any thoughts greatly appreciated, thanks.
If you look in the CalendarRuleBase table you should see a record with the data you gathered in your trace. You should also see another record created approximately the same time and it will have a CalendarId that equals the InnerCalendarId of the data from the trace. In this record there is a value - Offset which appears to represent the number of minutes past midnight for the start time. There is another value - Duration which appears to be the number of minutes of the shift.
I created work hours from 8-5. My offset was 480 (480/60 = 8) 8 AM start time and the duration was 540 (540/60 = 9) for a 9 hour shift.
It stumbled upon me while I was reading the query in another post.
Take the following query for example (ignore the non-practical use of the ordering):
SELECT
*
FROM Members
ORDER BY (TIMESTAMPDIFF(FRAC_SECOND, DateCreated , SYSDATE()))
Say "Members" table has a huge row count (or the query is complex enough for it to be executed over at least dozen of milliseconds). How does mySQL or other mainstream DB engines evaluate the "SYSDATE()" in the "ORDER BY"?
Say the query takes half a second, the microsecond (FRAC_SECOND) of "SYSDATE" changes 1000 X 1000 X 0.5 = 500 000 times.
My questions are:
Does the "SYSDATE" get fixed on the
start of the query execution or it
gets evaluated and changes as the
execution progresses?
If it's the latter, can I assume the ordering might be jumbled?
UPDATE:
My original post uses NOW as an example of dynamic value, it's SYSDATE now
NOW() returns a constant time that
indicates the time at which the
statement began to execute. (Within a
stored function or trigger, NOW()
returns the time at which the function
or triggering statement began to
execute.) This differs from the
behavior for SYSDATE(), which returns
the exact time at which it executes as
of MySQL 5.0.12.
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_now
In other words, it is executed only once when the statement is executed.
However, if you want to obtain the time at each execution you should use SYSDATE
As of MySQL 5.0.12, SYSDATE() returns
the time at which it executes. This
differs from the behavior for NOW(),
which returns a constant time that
indicates the time at which the
statement began to execute. (Within a
stored function or trigger, NOW()
returns the time at which the function
or triggering statement began to
execute.)
http://dev.mysql.com/doc/refman/5.0/en/date-and-time-functions.html#function_sysdate
Update:
Well, from what I know Order by will be executed or better said "used" only once. Since the value of TIMESTAMPDIFF(FRAC_SECOND, DateCreated , SYSDATE()) will be different every time you execute the SELECT statement. So, I think (once again I think) ORDER BY will consider either the first evaluated value of the timestampdiff or the last one. Anyway, I think by executing this - you will get a random order every time. Maybe there are better experts than me here who can answer better.