Expression summing from fields with dates

bevc

Registered User.
Local time
Today, 12:30
Joined
Jul 30, 2015
Messages
19
I apologise in advance for any poor forum etiquette or any general or specific database newbie dumbass-ery.

I am involved in centrally managing a project , a part of which involves employees of certain companies being given a weekly subsidy for study on academic courses.

Despite my newbie-ness (newbility?), I have successfully set up a table for all the learners and a related table for companies.

Each learner will receive a fixed weekly rate subsidy in the first year, and a lower fixed weekly rate subsidy in the second year. Somebody (not me) will need to check their paychecks to ensure that employees have been paid and all is above board. The learners/employees can start on the programme at any time. I need a way to track this (total claimed amounts, where they're up to etc).

My theoretical solution, is to have a field for each week a learner is on the programme (52 first year, 52 second), and instead of entering a currency amount in the field, the check-person can enter the date they saw the evidence and are happy with it. I thought then if I create a query that searches any dates that fall within the current claim period (eg >01/01/2015, <=Date()), and multiplies field count that fall within those parameters by first/second year subsidy rate if they’re in that table. I think my logic is sound, I’m just not sure how to write the query/expression, or if it's possible, or if there is a much simpler way to do it that I am too bone-headed to see.

I am new to databases and this kind of thinking in general, and I would be extremely grateful if any experienced Access hands could point me in the right direction or offer any advice at all (beyond "Get a different job, the one you have is over your head"). Thank you very much.
 
...is to have a field for each week...

Nope. Tables should grow vertically (with rows of data) and not horizontally (with columns of data. So you wouldn't have a field for every week. You would have a field to denote what week that record was for.


My advice is to read up on normalization: https://en.wikipedia.org/wiki/Data_normalization

Then manufacture some fake data. Open up Excel and start typing in all the data you think you will need (Student Names, Student Birthdates, SubsidyAmount, etc). Then work on making the tables you will need to hold that data in Access.

Then establish relationships in the Relationships tool and post back here a screenshot of what you have.
 
Nope. Tables should grow vertically (with rows of data) and not horizontally (with columns of data. So you wouldn't have a field for every week. You would have a field to denote what week that record was for.

Thank you very much for the reply, I'm sorry my lingo was wrong - I did mean that the table could only grow vertically - 'horizontally' it would be 53 columns (the field names being Student ID, then Week 1, Week 2, Week 3….Week 52), then against each student ID the data checker would input a date on which they 'signed off' on that learner for that week the learner completed. That would allow the fact checker to see the last time they had something from any particular learner (the last date they inputted), and because the subsidy amounts are fixed I could do a calculation based on date parameters (if I could figure out how to do that).

I don't know if that makes sense, it probably would help me if I mocked it up in excel rather than tried (and failed) to articulate concepts about which I know nothing. I will read up on data normalisation, thanks.
 
bevc,

Here is a tutorial from RogersAccesLibrary that will help you with database concepts. Starting with a business description it shows a process of how to identify and design tables and relationships. The process is applicable to any database.
The tutorial includes a solution. You have to work through(30-60 minutes) the tutorial to gain the benefits.
Good luck.
 
...'horizontally' it would be 53 columns...

That's exactly what I thought you meant and what I said you shouldn't do. You wouldn't have a table with 53 columns (StudentID + one field for every week in a year). You would have 2 columns and 52 rows:

StudentID, WeekNum
12, 1
12, 2
12, 3

Again, read up on normalization and give it a shot and post back here what you have.
 

Users who are viewing this thread

Back
Top Bottom