I ran a database in the way I described, although it was not for the
same purpose. It had over 1400 records, was simple to use, easily
expanded (adding more siblings, committee positions, etc.) and was fully
automated down to inserting ZIP codes when city/suburb were entered.

By compacting Access, empty fields do not take up space if the field
size is allowed to expand as required.

By careful design, the list view should show only those fields that are
important to see. The rest can be on the right hand side hidden by the
RH edge of the viewing area.

I sorted the list alphabetically and on the bottom of the form had each
alphabetical letter associated with a query that took me to the first
record starting with the letter selected.

I used a separate table to contain deleted records because I found that
some people came back and their name needed reinstating. Once again,
this was a one click operation.

To create a list of committee members (having used a field to indicate
their position on the committee - President, Secretary etc.) create a
form that calls a query that interrogates that field, extracts names,
positions etc. At the top of the original list view create buttons to
call all other forms (including the enter data form).

In other words, use forms with queries to show specific data instead of
separate tables. One advantage of using forms in this manner is that
contents of fields can be created by a query and buttons added to take
further action or to show additional information, such as print list of
committee members or address labels for those members.

There is another method of showing specific data but it has to be in the
same layout as the list view. Create a button that calls a query to show
only those records with a non blank committee field. Put the button at
the top of the list view. One click of the button and all committee
members will be displayed in lieu of the full list. You will need a
button to display the full list to get back to the original list view.

If you need some of the queries for doing this work please contact me
off list.

Good luck,

Orf

Peter Shkabara wrote:

>Hi Orf,
>
>Your approach is a simple way to handle it, but it misses the benefit of a
>relational database. For example, how many children do we provide for?
>Should it be 2, 3, 4? What if someone has eight children? Also, it seems
>wasteful to make room for a spouse and children when the person is single.
>This is the principle behind a relational database - no waste, but the
>design is more complex!
>
>The other problem with the single table approach is that it is very
>difficult to create other lists, such as members of a committee. If you have
>a table of names, all you need is another table that contains the ID entries
>for all members of a committee. If there is another committee, just create
>another table with the members' ID entries.
>
>Peter
>-----------------------------------------------
>The NoSpin Group
>[log in to unmask]
>
>
>
>
>>-----Original Message-----
>>What I would do is have one table using the following fields:
>>Title, Initials, First Name, Surname, Address1, address2, Address3,
>>City,  State, ZIP, Birthday, TitleW, InitialsW, First NameW, SurnameW,
>>BirthdayW, TitleC1, InitialsC1, First NameC1, SurnameC1,
>>BirthdayC1, .....
>>
>>
>
>             Do you want to signoff PCSOFT or just change to
>                    Digest mode - visit our web site:
>                   http://freepctech.com/pcsoft.shtml
>
>
>
>

             Do you want to signoff PCSOFT or just change to
                    Digest mode - visit our web site:
                   http://freepctech.com/pcsoft.shtml