Membership renewal dates when there are life members

Topic

New Reply

Need advice on the smart way to handle membership renewal dates when there are life members. I have an Access 2013 database for a historical society’s membership, which we use to send out newsletters. Renewals occur throughout the year, so I need to track when someone or a business renew by date. We do have a number of life memberships, so those entries won’t have a date.

I have a Yes/No field for Life Memberships and a date field for LastRenewed, and text field for MembershipRenewDate. The mailing label generated has the renewal date just under the name, so members can see when they need to renew next.

It is clear that I don’t have it set up well, but don’t know how to get what I need. What I would like a date field that I can query for who has renewed and who hasn’t, a means of accounting for the life members, and a way of printing the date the membership is paid up to/or Life. It isn’t a huge database with only 245 entries, so making changes will be easy once the structure is correct.

Appreciate any assistance.

Reply | Quote

Replies

Sueri,

What I’d do is to ditch the Life Member field and change the Renewal Date field to a type of Date then just enter a date of say 12/31/2200 for Lifetime Members, of course if you think your database will survive longer than that make it 2525 In the Year 2525. This will allow you to do date comparisons for those who need to renew (e.g. greater than the last day of the previous month and less than the first day of the next month) while easily avoiding the life members.

HTH :cheers:

May the Forces of good computing be with you!

RG

PowerShell & VBA Rule!
Computer Specs

Reply | Quote

Sueri,

What I’d do is to ditch the Life Member field and change the Renewal Date field to a type of Date then just enter a date of say 12/31/2200 for Lifetime Members, of course if you think your database will survive longer than that make it 2525 In the Year 2525. This will allow you to do date comparisons for those who need to renew (e.g. greater than the last day of the previous month and less than the first day of the next month) while easily avoiding the life members.

HTH :cheers:

Figured I was missing something easy. Thank you.

Reply | Quote

Great song!

cheers, Paul

Reply | Quote

Hi sueri,
If MembershipRenewDate will be used only as described in your original post, then RetiredGeek’s suggestion seems the most practical.

But, if you changed the database that way and then decided to create a report of all members and their membership renew dates, this would entail “translating” the dummy date of 2525 to “Life”.

In contrast, your present database structure explicitly recognizes the concept Life. This wouldn’t necessarily make our hypothetical report “easier” to construct, but it would make it more intuitive because your present database structure reflects the historical society’s “business rules” more accurately. This would probably also allow the database to meet unanticipated needs more gracefully.

Hope this helps,
Dave

Reply | Quote

Dave,
I’m going to keep the Yes/No field for Life Memberships, so that I can easily keep track of them. RetiredGeek’s suggestion will let me design a better query and sort the data better. I had to recreate the database last year from someone else’s work, but it was out-of-date. We are still figuring out what names to keep and delete. Once I’ve made the changes, I’ll create a few new queries so that I can print Life members, current members, and need-to-renew members labels separately.

Sue

Hi sueri,
If MembershipRenewDate will be used only as described in your original post, then RetiredGeek’s suggestion seems the most practical.

But, if you changed the database that way and then decided to create a report of all members and their membership renew dates, this would entail “translating” the dummy date of 2525 to “Life”.

In contrast, your present database structure explicitly recognizes the concept Life. This wouldn’t necessarily make our hypothetical report “easier” to construct, but it would make it more intuitive because your present database structure reflects the historical society’s “business rules” more accurately. This would probably also allow the database to meet unanticipated needs more gracefully.

Hope this helps,
Dave

Reply | Quote

I’d keep that “Life Membership” field. I think it is an important piece of information. I dislike using artificial entries (like 2525).

Reply | Quote

Leave the renewal value blank, or the earliest possible date, for life members. Still allows sorting on date but doesn’t upset your existing.

cheers, Paul

Reply | Quote