James said:
I'll try to come up with something better. I expect that others will
provide solutions to your specific question while I do that.
The way I would answer that post today might include:
qryCountBreaks:
SELECT TTID, BreakStart, BreakEnd, DateAdd("n", Hour(BreakEnd) * 60 +
Minute(BreakEnd), DateValue(PunchIn)) AS dt1, DateAdd("n",
Hour(BreakEnd) * 60 + Minute(BreakEnd), DateValue(PunchOut)) AS dt2,
IIf(DateDiff("d", dt1, dt2) < 2, 0, DateDiff("d", dt1, dt2) - 1) +
Abs(dt1 > PunchIn AND dt1 <= PunchOut) + Abs(dt1 <> dt2) * Abs(dt2 >
PunchIn AND dt2 <= PunchOut) AS CountBreaks FROM tblTimeTickets, tblBreaks;
That is, compute the end of the break on the PunchIn and PunchOut dates
(dt1 and dt2 contain the computed date values). Then count one break
for every full day between dt1 and dt2 that doesn't include dt1 or dt2,
then check the dates that include dt1 or dt2 recognizing that those
counts will be double if dt1 = dt2. Since dt1 and dt2 have the same
h:nn values there is always an integral number of days between them.
The SQL above seems to handle more situations than the previous solution.
I use comparison operators instead of using BETWEEN because I don't want
to count a break if it ends exactly where a PunchIn starts. BTW, by
using BreakStart in the calculations instead of BreakEnd and by shifting
the '=' for the date range comparison it's possible to move the closed
end of the interval to the beginning of the interval.
Since the durations in tblBreaks are all the same, counting breaks is
equivalent to counting the amount of time on break. You can use
DateDiff (with "n") to get the duration of an entire shift in minutes,
then subtract the break time.
So, to tell if a time (including the date), ti, is between two other
times, ts and te:
ti >= ts AND ti <= te
or
DateDiff('s', ts, ti) >= 0 AND DateDiff('s', ti, te) >= 0
or
ti BETWEEN ts AND te
I expect that regardless of the underlying implementation for dates, SQL
users will expect to be able to use comparison operators directly making
it quite unlikely that the current implementation of dates in Access or
SQL Server will change anytime soon. Still, I avoid performing
arithmetic operations on date values.
I tested the SQL using a break that ended soon after midnight and it
seemed to do the right thing for that situation. It may even be
worthwhile to think about including a shift number field in tblBreaks.
Be sure to test the SQL adequately if you use something like it for your
situation.
James A. Fortune
(e-mail address removed)