If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
|
Thread Tools | Display Modes |
#11
|
|||
|
|||
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] |
|
Thread Tools | |
Display Modes | |
|
|