address primary key

Hello John,

We hope you are not fed up with me. I am still curious to know why you said
not using 4-filed PK. Let me explain more details.

Our organization or office we can say is like this ( top down). sorry if my
English is maybe hard to understand :

1 General Conference(world level) consists of Divisions
2. Division Office consists of Unions
3. Union consists of regionals
4. Regional consists of churches

For your information, the information s I need is the membership and address

When I give my database(software)with blank data to Regional A, they start
filling in church id 1...2 and so forth

And when I give the the software to Regional B, they will also start filling
in their chruch id 1..and 2..and so forth...

In the Regional level, of course there is no duplicate, but when it comes to
the Union level, the Church Id of Regional A, say no. 1 will duplicate with
the church ID no1 of Regional B. That is why I suggest there should be 4
fieild primay key of member table and address table.

My question is since filling in the 4 field PK will be labourious in typing,
can we make in the form the default value in the Division PK, Union PK and
REgional PK, so that when they enter data it already gave the number?, the
only thing for them is to fill the chruch id and we can also make it
autonumber?

I apppreciate your patient to educate me.



--
H. Frank Situmorang


"John W. Vinson" wrote:

On Tue, 14 Oct 2008 02:01:01 -0700, Frank Situmorang
wrote:

Thanks very much John, this really help me, but the idea is very helpful,
especially our Seventh Day Adventist churches have the organization hirarchy
as follows starting from the lowest level:
1. Individual/local church
2. Regional Office
3. Union Office
4. Division Office
5. General Confrence ( World Office)

From what I learned from you, in the member table, we should have all the
above ID to be a primary key. Am I right?. The reporting system is bottom up.

Is it possible to make 5 fields to be a primarykey?. Now how about the
address table, should we make it like a member table? with other 5 fields to
be a primary key?, so that all unique?

Well, you don't need a variable field for level 5, since there's only one
General Conference (unless you plan to expand this database to include us
Presbyterians)!

I'd actually *not* use a four field primary key; it gets pretty hard to use
especially if you have related tables (such as group memberships, donations,
etc.) I'm not sure how much information you want to propagate "up" to the
regional, union etc. offices; it might be better to have just the ChurchID and
MemberID as a joint primary key, and have fields in the (separate) Churches
table to indicate which higher level offices that church is in.

If the Regional (union, division, world) office needs to know addresses, then
it would be sufficient to also have ChurchID and MemberID as a two field
primary key.

Have you checked with the General Conference to see if they already *have* a
member database? I would guess that they do. If not, maybe they'd be
interested; but there are enough Seventh Day Adventist churches and members
that you should really consider implementing this in SQL/Server (with an
Access frontend) rather than in a native Access database.
--

John W. Vinson [MVP]