This might not be what you had in mind, but this is how I approached the problem.
First, I didn't arbitrarily take down the DB ever. Instead, I had a schedule. If I was going to put up something, I only did it on that schedule. Never otherwise. Not unless Hell was freezing over and we were going to have to pay the heating bill to thaw it out again.
Second, I created a little table (ferreted away in a hidden table, actually) that contained the schedule of down times. It had start time, stop time, and event name. I could schedule as much as I wanted. Only one of them was "next" at any time. Needless to say, this table was READ-ONLY to the world but I had full rights to it.
Third, I had a startup form that you had to click a button to get rid of. BUT when you clicked the button, you didn't close it. You minimized it and made it invisible. It was still there, sitting in the background, waiting to do some neat things. The startup form had two functions that related to the schedule of maintenance. The form did a whole bunch of other things, too, but the parts that interest you are these two events:
In the Form_Load event, I checked to see if you were loading the form at a time between the two event times.
In a self-renewing Form_Timer event with a frequency of once per minute, I checked to see if the current time was between the two event times.
If either of these said, "Yes, it is now a time within the scheduled event time" then I popped up a warning form (unbound, really; just an excuse to hold a big message that I could display in a specific way) that told the user to leave. This warning was not a message box 'cause I wanted ANOTHER timer to run in that case, one that did a QUIT for me. (It's a DoCmd action, I think.) Message boxes can get in the way sometimes and this was one of them, so that's why the unbound form. Oh, the user couldn't close it directly. There was no "close" button on it. Well, there was, but it was not visible... Once that big warning box was up, I gave the users one more minute to exit cleanly before I whacked them. If they tried to close the form, it ALSO did a QUIT for them.
I also made them understand that I would be responsible about this usage. When maintenance was scheduled, I did repairs, compactions, upgrades, etc. but I never exceeded the boundaries of the schedule. Then I got blanket authority from the boss to take it down for X minutes once a week at the specified time where X = estimated time for repair, compact, backup, etc. If I needed more time than X, I got special permission and maybe added an odd-hours event to avoid times of heaviest usage. If I decided I did not need as much time as X, I adjusted the stop time on the event to reflect the time I really needed. If I didn't need any time at all, I deleted the scheduled down time entry and nothing much happened.
I also made the startup form tell the user how long before the next scheduled down time so they could plan their work, and my orientation on how to use the DB included a brief comment about the expectation of having some down time as a cost of doing business. Plus the veiled threat of dire consequences if they got in the way of protecting the company's investment of time and money that had gone into the DB.
Finally, I ran a query during maintenance so that all obsolete schedule entries would go away so they wouldn't clutter the schedule table. That way, I was always assured that I only saw future (or current) events, never past ones.
Since the query that found the "next" item just did a SELECT FIRST 1 etc etc etc WHERE EventStart>Now() AND EventStop <Now() ORDER BY EventStart; ... and the table's prime key was the starting time/date of the event, this minimized schedule searches a whole helluva lot.
