Dear Access Experts,
I am trying to build a system where candidates for a position will log in and, based on manager availability, select appointment times for interviews. Managers will be able to enter their availability (or lack thereof) by logging in as a manager.
Of course I will have all sorts of constraints, as each candidate will have to be interviewed by all three managers, etc, but I have basic design issues.
At first, I thought I should break the time into "slots" and have each manager input their availability for each slot with a checkbox. This can work, but I am motivated to try and find a way to give the managers the power to select ANY date and time range to be busy or free. I am told this will be more difficult but more desirable.
How do you recommend inputting availability for managers? Inputting when they are free, or when they are busy? As in table design, etc. the use of this database will be limited to allowing candidates to select from available time to make appointments, and to show managers their current schedule.
My thoughts: A manager would be limited in time to 9am to 5PM by default. Then, they would input when they want to be occupied. these would go to a table under "occupied". then, when a user is searching, results will be "any time between 9 and 5 that is not included in an entry on the "occupied" table.
The thing is, I would like to have managers input when they are available, rather than when they are not. So, if they say they are available from 12-2, I need to find some sort of date difference or calculation that generates the entries of 9-12 and 2-5 on the "occupied" table.
For the purposes of this project, do you think it is logical to base the table entries on occupied time or available time? I think occupied makes much more sense, as they are unchanging for the most part. an "available" entry of a time range would have to be chopped into two entries if an appointment was made in the middle of the period.
does anyone have any advice on this? I hope I made my aim clear enough.
Thank you,
MIke
I am trying to build a system where candidates for a position will log in and, based on manager availability, select appointment times for interviews. Managers will be able to enter their availability (or lack thereof) by logging in as a manager.
Of course I will have all sorts of constraints, as each candidate will have to be interviewed by all three managers, etc, but I have basic design issues.
At first, I thought I should break the time into "slots" and have each manager input their availability for each slot with a checkbox. This can work, but I am motivated to try and find a way to give the managers the power to select ANY date and time range to be busy or free. I am told this will be more difficult but more desirable.
How do you recommend inputting availability for managers? Inputting when they are free, or when they are busy? As in table design, etc. the use of this database will be limited to allowing candidates to select from available time to make appointments, and to show managers their current schedule.
My thoughts: A manager would be limited in time to 9am to 5PM by default. Then, they would input when they want to be occupied. these would go to a table under "occupied". then, when a user is searching, results will be "any time between 9 and 5 that is not included in an entry on the "occupied" table.
The thing is, I would like to have managers input when they are available, rather than when they are not. So, if they say they are available from 12-2, I need to find some sort of date difference or calculation that generates the entries of 9-12 and 2-5 on the "occupied" table.
For the purposes of this project, do you think it is logical to base the table entries on occupied time or available time? I think occupied makes much more sense, as they are unchanging for the most part. an "available" entry of a time range would have to be chopped into two entries if an appointment was made in the middle of the period.
does anyone have any advice on this? I hope I made my aim clear enough.
Thank you,
MIke