I want an alarm, that if it detects 3 occurrences in a range of 5 minutes, it launches an alarm.
Therefore:
If an alarm occurs, I understand that it must be before the time of first occurrence + 5 mins.
And that the state of alarm lasts until the time of the 3rd occurrence + 5 mins. (Bearing in mind that after the 3 occurrence there is no more)
Therefore, having my current configuration, I don't understand why the alarm state lasts so long.
Related
Some data gets logged every 10 hours for machines with an ID.
I want to do a timeplot with one point for every 24 hours.
How do I get the newest datapoint by ID for these 24 hour buckets?
I'm trying to find an efficient way to calculate the booked times for a user(object), given a list of free/available times for the same user\object.
I have an object that will return the "available" times for a given specific day. The duration/end time is fixed to 10 minutes.
Example Starting data:
12/23/2020 8:00 AM
12/23/2020 9:00 AM
12/23/2020 1:00 PM
In this case I need to generate the "unavailable" times and insert them into a database with a fairly simple schema:
start_date | end_date | start_time | end_time
The inserting is fairly trivial, i'm having a hard time determining the best way to calculate the unavailable timespans.
Using the example above i would need to generate the following timespans:
12/23/2020 12:00 AM - 7:59 AM
12/23/2020 08:11 AM - 8:59 AM
12/23/2020 09:11 AM - 12:59 PM
12/23/2020 1:11 PM - 11:59 PM
Any frameworks or libraries that can do the heavy lifting on this for me? Is it possible to solve this problem without looping through the results and calculating all of the offsets?
To anyone asking "why" - hooking together two legacy systems, one system returns the available appointments for a given date this needs to be plumbed into a system that needs the un-available appointments for a given date.
Well, first I written more tour booking systems then I can shake a stick at.
The one Rosetta stone that holds true?
You don't want to generate or have booking slots that are NOT being used in the system PERIOD!!!
Thus you ONLY ever enter into the system a valid booking (starttime, and end time). And that startTime should be a datetime column - this will VAST reduce the complexity of your queries. Given you have date and separate time? Well, then your queries will be more complex - I'll leave that to you.
Given the above? The simple logic to find a booking collision in ALL cases is this:
A collision occurs when:
RequestStartDate <= EndDate
and
RequestEndDate >= StartDate
Now in above, I assume date values, or datetime values.
So if I want a list of any booking for today?
RequestDDTStart = 2020-12-23 9 AM
RequestDTEnd = 2020-12-23 5 PM
And thus any collision can be found with this:
strWhere= dtRequestStartDate <= BookingEndDate" & _
" and dtRequestEndDate >= BookingStartDate"
Now, assumging .net, then above would be something like this as parameters
strWhere= #dtRequestStart <= BookingEndDate" & _
" and #dtRequestEnd >= BookingStartDate"
So, above would return all bookings for today 9 am to 5 pm
A REMARKABLE simple query! Now of course the above query could/would include the exam room, or hotel room or whatever as an additional criteria. But in ALL cases the above simple query returns ANY collision for that 9 am to 5 pm.
And the beauty of this system? As long as you never allow a over-lap into the booking system, then you can book a 10 minute or a 20 minute or a 30 minute session as ONE entry into the database. I would thus not need to create 3x 10 minute slots.
So, this means you NEVER have to create booking slots. The whole system will and can be driver with a simple start + end booking record. And as noted, then you can book 1 hour, or 40 minutes. Your input (UI) can simple limit the time span to increments of 10 minutes - but that's the UI part.
Now I suppose to display things in 10 minute increments on a screen? Well, then you would have to submit 6 requests per hour to "display" the time slots. For a whole day, that suggest for 9 am to 5 pm, you would have to run 8 x 6 = 48 requests to get a list of 10 minute increments. But then again, you COULD just show the existing bookings for a day, and allow new bookings to be added - but don't allow if there is a over lap.
So, as noted, the concept here is you don't really need "slots" in the database. I suppose you could try slots, but it makes the code a HUGE mess to deal with. if you ONLY ever store the start + end? Then I can say move the booking to another day by JUST changing the date. Or I can extend a booking from 10 minutes to say 20 or 40 minutes - and ONLY have to change the end time. As long as no overlap occurs with the above simple "test", then I can simple change the booking to be 40 minutes in length - and ZERO code to update multiple slots is required. And same goes for reducing a booking from 40 minutes to 10 minutes. Again ONLY the end time need be reduced - a ONE row update into the database.
So if at all possible, I would dump the concept of having "slots" in the database. I might consider such a design if a booking was only ever 10 minutes. But if 10 or 20 or 30 is allowed, then you don't need to store ANY un-used slots in the database, but ONLY ever store a valid booked slot. Empty un-used time can thus ALSO be found with the above query. (if the query returns records - then you can't book).
So display of free time in some UI becomes more of a challenge, but showing bookings that span 10 or 20 or whatever minutes is far more easy, and as noted, you can even change a whole booking to a different room by a ONE row update of the room ID. If no collision occurs, then you allow this booking - and you achieve this result by ONLY updating one simple booking record that represents that start + end time.
and this means you also NEVER store the booking totals in the database - you query them!
I also found that if I say store any booking totals in the database? Well, with complex code, we always found that the totals often don't match perfect. So then we wind up writing a routine to go though the data, sum up the totals and write those out.
But, if you never store any booked totals (say people on a bus, or people in a given hotel), then while the query for such display is somewhat more difficult, it becomes dead simple to remove a person from say a tour by simple null out of the tourID.
So, this display shows the above concepts in Action. And the available rooms in the hotel, people booked on bus, and even totals for "group tours" are ALL values NOT stored in the database:
So in above, people booked on bus, booked in rooms, and rooms used? All those values are NOT stored in the database. And no slots exist either. So if we have a bus, then we set the capacity of 46, but we do NOT create 46 slots to book into. So be it a bus, a hotel, a medical exam room? You don't create booking slots ahead of time, but simply insert bookings with a start + end, and then query against that concept.
So, to find a total on a bus (or say in a exam room), I query to find the total for that day. And if I want to move a group booking of 4 people from one bus to another? Then one FK update to the given bus they are on allows the whole system to "cascade" the existing values in the system. And same goes for moving a person from exam room #1 to #5. You only have to update the FK value of the exam room. If no collisions occur, then this again is a one row update. If you have multiple exam rooms, and multiple slots, then what should be a simple one row update in the database becomes a whole hodge podge of now having to update multiple booking slots with whacks of code.
So you book "use" of resources "into" a "day" a "bus" a room, but it is the act of that booking that consumes the time slots - not that you pre-create records or timeslots for each "range". This thus allows you to leverage the relatonal database model, and reduce huge amounts of code - since you not coding against "slots", but only that a exam room is open from 10 am to 4 pm. That available room for that day is thus ONLY ONE record you create in the system, and then you are now free to book into that one day given room range. The bookings into that one room for the day can be 10 minutes, or 40 minutes - but it ONLY one record being added into the database to achieve this goal (booking).
Regardless of the above, that simple collision query works for any collision (including a whole overlap, inside a existing span, or even the end or start overlaps any booking. And that query is dead simple - and it works for all collisions. So I don't have a library to share, but that simple booking collision finder query can thus drive the whole system based on that kind of simple query.
We're having trouble understanding the numbers in the daily summary emails we get from Fabric.
A search on SO only shows one somewhat-related question/answer.
Here are the emails from 2 consecutive days:
Our questions are:
Does “Monthly Active” mean over the last 30 days? If so, how can there be a 36% drop in 1 day if the counts went from 101 to 93 (an 8% drop)?
Why does “Daily Active” show a 75% drop if the current day is 1 and the previous day was 0?
Why does “Total Sessions” show a 94% drop if the current day is 1 and the previous day was 0?
Does the “Time in App per User” mean the average for the month or for the prior day? If it's for the month, why would 1 extra session cause the value to change so much? If it's for the day, why does it show “11:33m” even though the Total Sessions was 0?
Sometimes the “Time in App per User” ends in an “m” and sometimes it ends in an “s”. For example, “11:33m” and “0:44s”. Does that mean that “11:33m” is “11 hours and 33 minutes” and “0:44s” is “0 minutes and 44 seconds”? Or does the “11:33m” still mean “11 minutes and 33 seconds” and I should ignore the suffix?
Thanks for reaching out. Todd from Fabric here. The % change is actually % difference vs. what we expected based on the previous behavior of your app. This compensates for day of week etc.
The long session when getting zero, suggests that either the session was live/not reported to us at UTC midnight. The session gets created on session start and the duration gets set at the end.
Thanks!
I have a script that runs every 30 minutes that runs a query looking for new records within the previous 30 minutes. To account for any type of delay of the script running, I'd like to look in the pervious 0:00-30:00 minute, and 30:01-59:59 chunks.
For example, if my script runs at 11:00am, I'd expect it to find new rows that have an
entered_date > 10:30 am AND < 11:00 am
And when it ran at 11:30am, I'd expect new rows from an `entered_date > 11:00am AND < 11:30am.
Doing something like this only gets the last running 30 minutes:
SELECT
fa.entered_date,
fa.text
FROM
form_answers fa
WHERE
AND fa.value = 1
AND fa.entered_date >= DATEADD(mi, -30, GETDATE())
So if my script was somehow delayed by a few seconds, and ran at 11:00:02, I could potentially miss a record that has an entered_date of 10:30:01.
EDIT:
This is what ended up working for me:
fa.entered_date BETWEEN
DATEADD(mi,-30,CONVERT(VARCHAR(19),DATEADD(mi, DATEDIFF(mi, 0, GETDATE())/30*30, 0)))
AND
DATEADD(mi, DATEDIFF(mi, 0, GETDATE())/30*30, 0)
Depending on clock time in scripts is a bad idea. Your script may not run for some other reason -- SQL Server agent is not running, for instance, or the server is re-booted at just the time when it would run, or a new person accidentally unchecks a box. Or, it may run twice in some period.
If you want robustness, then keep a log table of the last time the script was run. Then read from the log, something like:
select #lastlogtime = max(lastreadtime)
from log;
And use this in your query instead of relying on the clock.
There is no sure-fire way to process "new" records based on time alone - even if you track the "last" processed time, there could be records that get missed, or records that get processed twice.
Some alternate methods:
Track the last entered_date that was processed and process anything that is added after that time.
Track the last ID that is processed, and process any records with a higher ID (assuming your table uses an incrementing key).
Add a flag or status field to your records to know if they've been processed or not
Use a queue that is filled when records are added (using a trigger) and processed periodically.
If you DO have to rely on the clock alone, then I would round the "current" time to the nearest 30-minute interval and lock back 30 minutes from there. So if the current time is 11:00:02, it would round it to 11:00:00 and process records that were added between 10:30:00 and 11:00:00.
I need to create a T-SQL (I`m using SQL Server 2008 Express) script (procedure/function) that takes entries from a "Tasks" table and generates only the tasks planned to occur in the next 5 hours.
In the "Tasks" table I should have tasks with job like properties :
Occurrence : One time or Recursive
Frequency : every x Days, Weeks, Months
Depending on the Frequency :
For Daily : every x hours,minutes
For Weekly -Days of the week when the task should occur
For Monthly - The first,second,last -day,week day,weekend -
day of week OR The 1st, 2nd, 3rd..31st of the month.
When I run the script I should get only the tasks that will occur in the next 5 hours or less in the case if task occurs every x minutes.
So what this script should actually do is use all the options from a SQL Server Job for a task.
Example1: I create a task "Check email" that occurs every day, between 14:00 and 15:00 . When i run the script at 09:00 I would get Task:"Check email" Time:5 hours left until task, because it occurs every day, i should be able to get this result every day when I roll the script ,only if that 5 hours or less range .
Example2: A task "Send hours report" that occurs Monthly, on the 1st week day (not weekend), at 01:00 PM . Running the script on the first week day of the month at 08:00 AM I should get Task:"Send hours report" Time:5 hours until task
I know it's a quite big request but hopefully someone will find it easy what for me seems pretty hard.
You should also store somewhere the date/time of the last execution of each job (at least for jobs that are configured for every x hours/minutes). The idea is to calculate the next execution date/time for each job, and return it if it's less than 5 hours away. If the job is configured for every x hours/minutes, use DATEADD and check if the result is within the configured timeframe. If the job is configured for daily (at a specified time), just check if the specified time is less than 5 hours away (but still in the future). I have done a similar feature and it's not an easy thing to check for all cases (it took me a few days of coding).