Name & Address form

[Dennis]

Hi,

I've have a membership database / form to create. There can be multiple
members per household (husband, wife, children).

I've read the article that says I should have and Address Table (1 entry for
the address) and a Name Table (1 entry per name and associate names with
address table via foreign key).

I understand the above. However, what I'm having problems with is creating
a data entry form where I can EASILY allow the user to enter the address just
once and associate multiple names with that single address.

Does anyone know of a sample form some where or a suggestion on how to do
this easily, from the user's point of view.

Thank you for your assitance.

 

[Jeff Boyce]

Dennis

So, one approach might be to use a main form to display the Address info,
and a subform to hold any/all persons.

Using a combobox to list possible persons on that subform would be one way
to give the users a simple way to select who lives at the address.

If your data relationship is something like:

* one address can have many people there
* one person can only have one address

then you could add an AddressID field (a foreign key) to your person table
to show which address s/he lives at.

Good luck!

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or psuedocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

 

[KARL DEWEY]

Create and address table with primary key (autonumber) and then create a
one-to-many relationship to people table. Then in the form for people have
combo (auto expand) to select their address.

 

[John W. Vinson]

Hi,

I've have a membership database / form to create. There can be multiple
members per household (husband, wife, children).

I've read the article that says I should have and Address Table (1 entry for
the address) and a Name Table (1 entry per name and associate names with
address table via foreign key).

I understand the above. However, what I'm having problems with is creating
a data entry form where I can EASILY allow the user to enter the address just
once and associate multiple names with that single address.

Does anyone know of a sample form some where or a suggestion on how to do
this easily, from the user's point of view.

Thank you for your assitance.

I've got a database (designed for church membership, though there's nothing
particularly "churchy" about it) that does exactly this, and also allows the
creation of any desired number of Groups, such that each person may be a
member of any number of groups; it will generate mailing labels, envelopes,
and direct dial phone calls to a member or to a group. Drop me an email at
jvinson <at> wysard of info <dot> com if you would like a copy of the
database.

 

[Dennis]

Karl, Jeff,

I forgot to mention the data entry source document. I have a membership
form from which the people are doing data entry. It does not lend itself the
the above database structure. There is one form per person and ti stands
alone. There is no reference on the form to any other form other than the
spouce name.

I fully understand the database side of it. However, I am having problem
translating the data entry form to the database structure. What we are
proposing for the user interface is unnatural from the user and data entry
stand point.

From a data entry stand point, it is unnatural to enter the address first
and then the name. I was trying to figure out a more natural presentation
for the data entry personel & other users. They are not going to understand
why we are entering address first and then name.

Second problem with the data entry part. If there are three room mates, all
are assigned to an address. When one moves out, two of them keep the same
address and the third one has to change their address. In the change of
address, you would have to use a different data entry screen to pull up by
member name and then enter their address.

Also, we have seasonal residents. Mom, dad, and son live in one house.
However, in the summer time mom and dad move to a different address up north
and the son stays in the local house. Then in the winter time, mom and dad
move back to the local address.

Also, the change of address come in for each member. I can see confusion on
the data entry people's part when one person changes to address on one member
but another one tries to change the address for the second person, but finds
the address already changed.

While I fully understand the database structure part, I don't see an easy
and elegant way to implement this from a data entry point of view. Remember,
the user's think in terms of individual members and not house holds. We are
forcing them to change how they think and this is going to be a HUGE change
management issue! Trying to implement this change will require over comming
massive user resistance and huge amount of training and hand holding not to
mention the amount of programming to handle all of different ways to add,
change, and delete the names and addresses independently.

I'm trying to find a simple, elegant way of creating a "normal name and
address" data entry form than is consistent with the user's current though
process but yet allows me to implement the desired database structure. That
is where my problems lies.

 

[Dennis]

John,

I set you an e-mail at the address you supplied above. Please let me know
if you did not receive it, which means that I type it wrong.

Thank you very much for your asstiance.

 

[John W. Vinson]

I set you an e-mail at the address you supplied above. Please let me know
if you did not receive it, which means that I type it wrong.

Message received, database sent. Hope it works well for you!

 

[Larry Linson]

So, your main form is for entering/viewing the person, and your subform is
the address data... you can either choose an existing address or enter a new
one. What's the problem? You surely did not expect to find a solution using
exactly the form you already have, did you?

Larry Linson
Microsoft Office Access MVP