Attendance/Membership/Dues Database Example (1 Viewer)

Pat Hartman

Super Moderator
Staff member
Local time
Today, 08:02
Joined
Feb 19, 2002
Messages
42,970
I'm pretty sure that was implied in pekajo's question. So go do it now. Do not wait for a reply here.
 

pekajo

Registered User.
Local time
Today, 23:02
Joined
Jul 25, 2011
Messages
132
I'm pretty sure that was implied in pekajo's question. So go do it now. Do not wait for a reply here.
No, just from here? Should I have done so?
Just realised I can add it here.
For anyone who uses the database can you just let me know.
Thanks
Peter
 

Attachments

  • Chips.zip
    4.1 MB · Views: 153

pekajo

Registered User.
Local time
Today, 23:02
Joined
Jul 25, 2011
Messages
132
Just realised I can add it here.
For anyone who uses the database can you just let me know.
Thanks
Peter
Forgot to add. The Backend needs to be in C:\Chips\ folder or change the link tables within the Front End.
 

Steve R.

Retired
Local time
Today, 08:02
Joined
Jul 5, 2006
Messages
4,617
Unfortunately, I can no longer view an MS Access database, so I can't view your data-structure. But as a quick observation:
MembershipStatus Table - One record per member (Fully Paid, Retired, Student, Widow, etc)
The table above appears unnecessary since the members status is an integral component to the " Members Table - One unique record per member (Personal Details, Contact Details)". I would suggest the creation of a "Membership_Category" table which simply lists the categories "Fully Paid", "Retired", "Student", etc. For example: "Fully Paid" would have a primary key of "1" and that would appear as a foreign key in the "Members Table".
 

pekajo

Registered User.
Local time
Today, 23:02
Joined
Jul 25, 2011
Messages
132
Unfortunately, I can no longer view an MS Access database, so I can't view your data-structure. But as a quick observation:

The table above appears unnecessary since the members status is an integral component to the " Members Table - One unique record per member (Personal Details, Contact Details)". I would suggest the creation of a "Membership_Category" table which simply lists the categories "Fully Paid", "Retired", "Student", etc. For example: "Fully Paid" would have a primary key of "1" and that would appear as a foreign key in the "Members Table".
HI,
This database was not a review. You either use it or not. Simple.
Peter
 

Steve R.

Retired
Local time
Today, 08:02
Joined
Jul 5, 2006
Messages
4,617
HI,
This database was not a review. You either use it or not. Simple.
Peter
While the sample database may be: "either use it or not" and not subject to review, sample database tend to require tweaking to fully meet a user's expressed needs. Though @Mebd does not imply that the sample database (which I cannot see) actually requires tweaking; @Mebd's post has raised apparent concerns that need to be resolved as expressed in his or her post below. The post ends with the question: "Does that make sense and have I missed anything?" That is what I was responding to. The sample database was was not the subject of my post and was consequently irrelevant.
Thanks everyone.

Having read and looked at the sample dbase I think that I need as follows;

Members Table - One unique record per member (Personal Details, Contact Details)
MembershipStatus Table - One record per member (Fully Paid, Retired, Student, Widow, etc)
MembersAddress Table - many address to one member (Home address(es)
AnnualSubscription Table - many years subscription to one member (from date joined to current year, whether paid or not, receipt number, etc)
Attendance Table - many records to one member (holds if we invited them to a meeting, attended or not, sent apologies or not

From there I think I need a number of forms for input and various reports

Does that make sense and have I missed anything?
 
Last edited:

Users who are viewing this thread

Top Bottom