tags:

views:

34

answers:

2

At work we've got a roster that's historically been maintained in a huge Excel workbook. That's getting a bit fragile because of staff changes and such, so I'm trying to re-implement it robustly as an Access database.

I've got a table of People (fields include name and some other attributes of people) and a table of Vacations -- each vacation has a person_ID, a start date and an end date.

What I'd ideally like to be able to generate from this is a roster grid like we had in the Excel workbook:

Date    Person A    Person B    Person C
01 Jan  -           -           -
02 Jan  -           -           -
03 Jan  VAC         -           -
04 Jan  VAC         VAC         -
05 Jan  VAC         VAC         -
06 Jan  -           VAC         -
07 Jan  -           -           -
08 Jan  -           -           -
09 Jan  -           -           -

(In this example the Vactions table has two records -- one for Person A, and one for Person B.)

Is that kind of thing possible with Excel? Or am I going to have to write some code?

Thanks!

+2  A: 

You could do that with a pivot table in access however displaying data like this is a classic symptom of “Excel to access/database” syndrome.

Mild Tangent

I was always told to thing that in a database there are only 3 numbers 0, 1 and n where n is any number between 2 and infinity. Displaying the data like that is fine when you have a small number of staff but what happens when you get 50 or 300 members of staff? I would look at displaying the data in a different way possibly an interactive form or other type of dynamic display. If it has to be paper then maybe some kind of report broken down per person?

/Mild Tangent

Kevin Ross
+1  A: 

I would recommend

  • Building yourself a date table (a table with a row for every date you're likely to use, say 01/01/2000 to 31/12/2020)

  • With the help of this table build a view that lists each date for each person and shows if that person is on vacation or not on that date (left join between vacation and date table and join between vacation and person)

  • Now the trickier bit. You now need to build yourself a cross-tab query.... but with access that can be fun (haven't used access for a while so maybe wrong on this).

  • However, I would recommend building the view in the 2nd step above and then using the power of Excel to build a pivot table of the data for you. Link your Excel spreadsheet to your Access database and every time your user needs a refresh of the data, they, urm, refresh it!

HTH

CResults
I can see how that would work, though building a table with a list of dates like that seems a bit hacky.
Stewart Johnson
**:-o** Hacky? *Hacky!?* :-) Believe it or not using a dates table is a very well recognised way of handling a problem such as this. The only real alternative to finding dates where there are no vacations is to use the less efficient method of looping, which also goes against the set nature of SQL.
CResults
I guess whatever I'm going here it's going to feel a bit like putting a square peg in a round hole. This question has a lot of variations on the same idea: http://stackoverflow.com/questions/510012/get-a-list-of-dates-between-two-dates
Stewart Johnson
Yep, all come back to essentially the same thing though, either a table of dates (be it permanent or temp) or a table of numbers from which a date is derived. You're a bit more limited in Access than you are in a bigger database such as MSSQL or Oracle so I would recommend having a permanent date table.
CResults
How is Access (or, more properly, Jet/ACE) limited compared to SQL Server or Oracle?
David-W-Fenton
@David In this instance Access does not support CTE's. Using a CTE you could build the dates table on the fly within the query.
CResults
Well, depending on the interface you're using, you could use the features of your data interface to do this, e.g., in ADO, with disconnected recordsets, and in DAO you can fake disconnected recordsets with transactions that create the tables but then discard them when the transaction closes. Not pretty, but doable. In this case, I can't see the advantage in not simply creating a persistent table for it, though, particularly if it's something you're going to use often throughout your application (as opposed to a one-off).
David-W-Fenton