Hi Lisa,

From what I can see, StrayBullet's solution is a more expert way to do what
what you are trying to to do. Hopefully it will work well for you. In a
lot of years of doing this for volunteer organizations, I've seen that "more
expert" can be a minus or a plus. Hopefully for you it will be a 100%
plus. If any more questions, would be happy to answer.....I probably won't
be monitoring this thread unless you let me know at tureks at ameritech
dot net.

Sincerely,

Fred

"Lisa - NH" wrote:

Hi Fred,

1. What are the main uses of this information system? Record current
status? Create reports? Long term / historical record keeping? Print
Badges? Drive the newsletter mailing?

In reading further, yes the answer is many of the above. First off, I am
the membership chairman (along with secretary & treasurer) for our American
Legion Auxiliary. Originally I was keeping an Excel file for this
information and sending updates to the person who was in charge of the post
newsletter at that time. My husband took over as Post Editor and I maintain
the mailing list. But it's more than that. I'm now actually maintaining the
full rosters for the whole post. A main file (that is NOT touched), is kept
on the post computer just in case anything were to ever happen to any of the
membership chairmen. Seperate Excel files are broken out of that file for
them to edit. The SAL is doing great as they highlight anything that they've
changed or added so we can update the main file. The Legion isn't quite as
good about this yet.

So we use it to keep track of all 3 organizations. It is helpful if we keep
at least the current year & previous years payment information. We do a
newsletter (so there are also a list of people not members who get this). We
don't necessarily need to print reports that often but we do need to
occasionally print out a roster by organization. We don't necessarily need
to have a long term history as the "paper" rosters are kept for this.

2. In the context of your answers to #1, and, yes, knowing all of those
variations that you talk about, is there sort of one core status at the
center of all of these? Like (being deliberately vague) "member", or "gets
the newsletter".

It used to be just for the purpose of sending out the newsletter (except for
the Auxiliary part). Now it's very important that it keeps full track of the
membership and to print the labels for the newsletter. (Note: I also print
laels out at the begining of each year for each organization for sending out
membership cards.)

3. How big is the organization?

The total between all 3 "groups" and the courtesy people is 1000.

After playing with the program and changing things around. I don't like the
all data in one table concept. Too many check boxes and too easy to screw
something up I think. Also I want to avoid having to re-do queries & forms
every year.

If the answer to #2 is "no" then what you really have is separate
organizations / tables which merely draw from a common list of people. In
that case, makke one "people" table (with numbers for them) which has their
non-organization data (name, address etc.) with a primary key(e.g. "persnum")
and a separate table for each organization which links to / draws from the
people table. And that organization table has fields for everything that it
needs to track.

I appreciate the info. I'm leaning more toward the setup the StrayBullet
mentioned as it was actually closer to what I was thinking about breaking
things down to after doing reading/research. It's sorta making a little more
sense to me now. I'm sure many more questions are going to arise as I go
along. Especially once I "hit" forms.
Lisa