Still Struggling...

I posted again but for whatever reason it is not appearing here. You may have
to go to Access Monster to read it. I see it there.
--
Aria W.


"Beetle" wrote:

OK, this post may get a bit long winded, so hopefully you won't pass
out from boredom before you get to the end.

To start with, I would like to clarify some aspects of the relationship types.
I will cover each type separately, using your data for examples.

1:1
***
You have a 1:1 relationship between tblEmployees and tblSiteEmp. In
this case tblEmployees could be thought of as the "Parent" table and
tblSiteEmp is the "Child" table. tblSiteEmp is the child because it is
dependent upon tblEmployees. You can have an employee in
tblEmployees without a related address in tblSiteEmp, but you cannot
have an address in tblSiteEmp without a related employee in
tblEmployees.

The rules of this relationship also state that there can be only one
child record for each parent record. Because of this, the child
table (tblSiteEmp) does not need a separate primary key. EmpID would
be the PK for both tables. In tblSiteEmp it acts as both the PK for that
table and the FK to tblEmployees. In the parent table it can be an
Autonumber but in the child table it cannot, because its value must be
derived from an existing PK value in the parent table. When a new
address record in entered in tblSiteEmp, an existing EmpID from
tblEmployees is inserted into the EmpID field in tblSiteEmp. Now, when
I say that the value is inserted, keep in mind that all data entry is
done through forms, and that the form handles this process automatically.
Your users would never even see the PK value, nor should they.
In this case the tables might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblSiteEmp
********
EmpID (PK/FK - long integer number)
Address
City
State
ZipCode


1:M
***
For this example I am going to use tblEmployees and tblPhones, but with
a couple of "disclaimers", so to speak.

1) There has been some back an forth in previous posts about whether
a phone should be related to a Room or an Employee, as well as
whether the relationship should be 1:M or M:M. I don't know enough
details to answer either one of these questions, so this is only an
example
of how to set up a 1:M relationship.

2) I agree with Bruce in that an employees home phone and personal cell
phone are part of their personal information, and therefore belong
in tblEmployees, not tblPhones. IMO tblPhones should only store data
about phones that are owned and maintained by your school, which
may include cell phones *if* they are owned by the school and are
assigned to employees.

So in this relationship tblEmployees is again the parent, and tblPhones
is the child. In this case we are allowed to have more than one child
per parent, so the child table does need to have it's own PK. In this type
of relationship the Foreign Key goes in the child table, or the table
that is on the "many" side of the relationship. So EmpID goes in
tblPhones as a FK, not the other way around (which is how you have
it now).

Another way of thinking about this is that a parent record does
not necessarily have a child, but every child record must have a parent.
Therefore, for every record in the child table, we need to know who
the parent is. So the tables might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblPhones
*******
PhoneID (Autonumber PK)
EmpID (FK to tblEmployees - long integer number)
PhoneDescription
PhoneNumber


M:M
***
You have more than one of this type, but I will use Employees and Titles
for the example. As you know, this type of relationship needs a junction
table. You can also look at this as two 1:M relationships where the
junction table is the "many" side in both relationships. So you have;

tblEmployees 1:M tblEmployeeTitles

tblTitles 1:M tblEmployeeTitles

So the combination of the two constitutes;

tblEmployees M:M tblTitles

Now, as I said previously, the "many" side table holds the foreign key.
So, in this case, the junction table holds two FK's, which you have
done correctly in your junction table. Where you went wrong is by
putting EmpTitleID in tblEmployees as a FK.

In fact, EmpTitleID does not need to exist in *either* table. In a
junction table, it is the combination of the FK's that constitute the
PK. In other words, each individual FK can be repeated many times,
but for each record the *combination* of the FK's must be unique.
The way you have it now, with EmpTitleID as the only unique identifier,
there is nothing to prevent the same title being assigned to the same
employee many times over. Now, you could leave EmpTitleID as the PK,
and create a unique index on the two FK's, but that would be ignoring
the fact that EmpTitleID is unnecessary. It is not good practice to
introduce unnecessary elements into your db. To create the proper
PK in this table, you would highlight both FK fields (EmpID and TitleID)
in design view, and then set them as the PK. For this example, the
table structure might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblTitles
******
TitleID (Autonumber PK)
TitleDescription

tblEmpTitles
*********
EmpID (Fk to tblEmployees and first part of PK - long integer number)
TitleID (FK to tblTitles and second part of PK - long integer number)

This same basic concept/structure should apply to your M:M relationship
between Employees and Classifications also.

Still awake?..........Hello?........ Pick your head up off that desk. Sleep
on
your own time, dammit! ;-)


So now, let's move on from concepts to things that are more specific
to your application.

First, let's try to sort out the Department and Subject relationships. If all
you were tracking was teachers this would be a bit simpler, because you
would only need to relate them to Subjects. Since each Subject would
belong to a Department, then you could determine what Departments a
teacher is related to by virtue of the Subjects they teach. You would not
need a direct relationship between the teacher and the department.

However, that obviously will not work for you because not all of your
employees teach a Subject but, presumably, they do all work in some
Department. So essentially, as I see it anyway, you have two separate
M:M relationships that you need to keep track of. Don't worry, it's
not as complicated as it may sound at first. Right now you have
tblDeptSubjects, which isn't quite right because in this case the
relationship isn't between Departments and Subjects. Basically you
have;

tblEmployees M:M tblDepartments

tblEmployees M:M tblSubjects

So the junction tables would be tblEmpDepartments and
tblEmpSubjects and the structure might look like;

tblEmployees
**********
(same fields as in the previous examples)

tblDepartments
***********
DeptID (Autonumber PK)
DeptName

tblSubjects
********
SubjectID (Autonumber PK)
SubjectName

tblEmpDepts
*********
EmpID (FK to tblEmployees and first part of PK - long integer number)
DeptID (FK to tblDepts and second part of PK - LI number)

tblEmpSubjects
***********
EmpID (FK to tblEmployees and first part of PK - LI number)
SubjID (FK to tblSubjects and second part of PK - LI number)

So in essence, your Subjects table has evolved. It is not just a way
to track subjects that are taught. Rather, it is a way to describe a
persons role within a Department. It would still include values that
describe subjects like Economics, European History, and the like, but
it would also have values like Department Chair and Custodial Staff.


Moving on again, addressing some specific things from your last post;

4) You appear to have no relationship between an employee and
the dept. they work in or the subject they teach.

What?! Please see above. I thought I had. I thought it should be in
tblSiteEmp.

I didn't notice the field in tblSiteEmp at first. I can see why you thought
it should go there. It's because you misunderstood where the FK's go.
You thought they belonged in the "One" side table. You then probably
thought if you put it in tblEmployees, you would end up with an empty
field in the Substitute teacher records, so you put it in tblSiteEmp. This
is actually wrong for two reasons;

1) As discussed before, the FK's don't go in the "One" side table

2) tblSiteEmp exists for one reason only. To store address information
for your full time staff. Employee names are not in tblSiteEmp, so
if you were to relate something to tblSiteEmp, you would essentially
be relating it to an address, which would be somewhat meaningless
without a name. I can see no scenario in which you would relate
anything to tblSiteEmp (other than tblEmployees, which is its parent).

I admit I haven't resolved how I am going to work Preferred Subject or the
Subs Credential (if they're Certificated) into the mix. I was thinking maybe
I could just list it under Subject but that brought up other issues that was
going to complicate things even more.

For Preferred Subject, just add a field to tblEmployees and have the users
manually enter whatever the preferred subject is. This will add relatively
little to the data entry process, and it will prevent you from having to
add yet another relationship to your db. If you end up with a few records
where the PreferredSubject field is empty, I think that's acceptable.

As far as the Subs credentials, that would be handled in the same manner
as the full time staff. If they have some type of credential, then there will
be a record in tblEmpClassifications to reflect that fact. If not, there won't
be a record. Simple.

This is where I decided to add Substitutes. It seemed to me to be an
attribute/sub-type of employee. True? Administrators can belong to both
Certificated and Admin. but I don't even want to get into that. For my
purposes, they are Administrators, period. That is of course unless you two
present a situation where I will need to revise that (shudderplease
don't...it's getting complicated).

I agree. An Administrator is just that. Let's not add any more complication.


Well, that's my two cents worth. Keep in mind that some of this is just
my opinion. Someone else may disagree with some of what I've suggested
because it is probably not *fully* normalized, but I think it's normalized
enough that it would be completely functional. Once you get your head
around how the relationships work, it should start to come into focus.
Hopefully I didn't get carpel tunnel for nothing :-)

BTW - Howcome I have to put in my two cents worth, but I only get a
penny for my thoughts? g

--
_________

Sean Bailey

Hi Aria,

You have been at this for over two weeks!!! Do you want to stop struggling?
I provide users a resource help with Access applications for a very
reasonable fee. I can design your table structure for you and provide you a
map of the tables. The map will show all the tables you need and for each
table the map will show the the name of the table, all the fields in the
table, the primary key and all foreign keys in the table. The map will also
show all the relationships between the tables and for each relationship will
show the type of relationship. You will then be able to keep the map at your
fingertips when you design the forms and reports for the database and their
associated queries. If you want my help, contact me at .

Steve



"Aria" wrote in message
...
Hi,
I'm still struggling to organize my tables and fields but I'm not as
*totally confused* as my original post; at least I hope I'm not. I'm new
to
Access. This is my first database and I fluctuate between feeling hopeful
I
can do this one minute and despairing that I can't the next because I've
thought of yet another complication that I don't know how to handle. I
have
scoured the Internet and this disscussion group searching for the answers
that I need. I found some but I am still at a loss as to what to do about
others. I was wondering if someone would be kind enough to review my table
structure and respond to some questions at the end. I am truly grateful.

The information is as follows:

tblEmployees
Inactive- Yes/No
Date- Date/Time
Date Modified- Date/Time
Employee ID- (PK) Auto number Long Integer
School Data (Classification, Title, Dept. Name, Subject)- text
Personal Info (LN FN MI etc.)- text
Emergency Info - text

tblKeys
Key ID (PK)- text
Campus- text
Wing- text
RoomType(Classroom, Auditorium, Grand Master, etc.)- text

tblKeysEmployees
Key ID- composite key(FK to tblKeys)- text
EmployeeID-composite key (FK to tblEmployees)- Autonumber

tblKeysRequests
Request ID-Autonumber
Key ID (FK to tblKeys)- text
Emp. ID
Rm. number- text--I think there is a problem here. This info is part of
tblrooms.
Rm. phone- text
Date Requested- Date/time
Date Recvd.- Date/time
Date Issued- Date/time

tblRooms
Key ID (PK)-text
Room number- text
Remarks-text

tblSubs
Sub ID (PK)-Autonumber
SubLN-text
SubFN-text
MI-text
SubPhone-text
Key ID (FK to tblKeys)
Date Issued-Date/Time
Date Returned-Date/Time

If you're still reading, I have the following questions:
1. How many fields are too many in a table? I understand that Access will
accept up to 255. I read a post that suggested that 20-30 fields may
indicate
there may be a normalization problem. I'm wondering about tblEmployees
where
there are approx. 25 fields.

2.tblRooms has a field for Rm.#; the problem is that not all rooms have a
#.
Ex.-Storage rms., clinic, auditorium, etc. This is why I added remarks to
tblRooms because I may have to describe a location rather than a room #.
Will
there be a problem with this method?
One of the desired reports is a reverse directory by room #/room phone #.
The phone # is currently in tblEmployees. Should it be moved to tblRooms?
If
I leave it where it is, will I be able to update any queries and reports?
I've read that multitable queries aren't updateable. We have had mass
staff
room changes right before the school year begins. It just seems it would
be
better if the phone # was listed with tblRooms but someone told me that's
incorrect.

3. I forgot to include the following fields: Date assigned, Return Date
and
Permission to Retain (over the summer) for Emp. Keys. Should this be added
to
tblKeys or tblEmployees? I was told not to put *anything* into the
junction
table (tblKeysEmployees) besides the composite key already listed.

4.Keys Requests--Somethimes are request will not have a name associated
with
it. For instance, we need to request a key for the vault. I have not
accounted for this situation and don't know how to handle it. If I need to
order a sub. key, I can use the name of the permanent staff member
associated
with that room. What do I do about the vault? Should I enter "vault" in
the
emp. table w/o any additional data?

5. Maybe I should cross this bridge when I get to it but I eventually will
get to the point where I will make forms and subforms. There are approx.
400
seperate keys, not including multiple copies of the same key. If I have a
combo box, is there a way to filter so that I am not looking at all 400
possiblities at once?

I am so sorry if this is too long and I'm asking too many questions at
once.
I understand that you are trying to help as many people as possible. I
have
searched and searched for answers and tried to adapt the customers/orders
format as much as possible to my situation but...I need help.

--
Aria W.

Doesn't me I'm not making progress. Sorry, I didn't realize their was a time
limit on learning.
--
Aria W.


"Mark" wrote:

Hi Aria,

You have been at this for over two weeks!!! Do you want to stop struggling?
I provide users a resource help with Access applications for a very
reasonable fee. I can design your table structure for you and provide you a
map of the tables. The map will show all the tables you need and for each
table the map will show the the name of the table, all the fields in the
table, the primary key and all foreign keys in the table. The map will also
show all the relationships between the tables and for each relationship will
show the type of relationship. You will then be able to keep the map at your
fingertips when you design the forms and reports for the database and their
associated queries. If you want my help, contact me at .

Steve



"Aria" wrote in message
...
Hi,
I'm still struggling to organize my tables and fields but I'm not as
*totally confused* as my original post; at least I hope I'm not. I'm new
to
Access. This is my first database and I fluctuate between feeling hopeful
I
can do this one minute and despairing that I can't the next because I've
thought of yet another complication that I don't know how to handle. I
have
scoured the Internet and this disscussion group searching for the answers
that I need. I found some but I am still at a loss as to what to do about
others. I was wondering if someone would be kind enough to review my table
structure and respond to some questions at the end. I am truly grateful.

The information is as follows:

tblEmployees
Inactive- Yes/No
Date- Date/Time
Date Modified- Date/Time
Employee ID- (PK) Auto number Long Integer
School Data (Classification, Title, Dept. Name, Subject)- text
Personal Info (LN FN MI etc.)- text
Emergency Info - text

tblKeys
Key ID (PK)- text
Campus- text
Wing- text
RoomType(Classroom, Auditorium, Grand Master, etc.)- text

tblKeysEmployees
Key ID- composite key(FK to tblKeys)- text
EmployeeID-composite key (FK to tblEmployees)- Autonumber

tblKeysRequests
Request ID-Autonumber
Key ID (FK to tblKeys)- text
Emp. ID
Rm. number- text--I think there is a problem here. This info is part of
tblrooms.
Rm. phone- text
Date Requested- Date/time
Date Recvd.- Date/time
Date Issued- Date/time

tblRooms
Key ID (PK)-text
Room number- text
Remarks-text

tblSubs
Sub ID (PK)-Autonumber
SubLN-text
SubFN-text
MI-text
SubPhone-text
Key ID (FK to tblKeys)
Date Issued-Date/Time
Date Returned-Date/Time

If you're still reading, I have the following questions:
1. How many fields are too many in a table? I understand that Access will
accept up to 255. I read a post that suggested that 20-30 fields may
indicate
there may be a normalization problem. I'm wondering about tblEmployees
where
there are approx. 25 fields.

2.tblRooms has a field for Rm.#; the problem is that not all rooms have a
#.
Ex.-Storage rms., clinic, auditorium, etc. This is why I added remarks to
tblRooms because I may have to describe a location rather than a room #.
Will
there be a problem with this method?
One of the desired reports is a reverse directory by room #/room phone #.
The phone # is currently in tblEmployees. Should it be moved to tblRooms?
If
I leave it where it is, will I be able to update any queries and reports?
I've read that multitable queries aren't updateable. We have had mass
staff
room changes right before the school year begins. It just seems it would
be
better if the phone # was listed with tblRooms but someone told me that's
incorrect.

3. I forgot to include the following fields: Date assigned, Return Date
and
Permission to Retain (over the summer) for Emp. Keys. Should this be added
to
tblKeys or tblEmployees? I was told not to put *anything* into the
junction
table (tblKeysEmployees) besides the composite key already listed.

4.Keys Requests--Somethimes are request will not have a name associated
with
it. For instance, we need to request a key for the vault. I have not
accounted for this situation and don't know how to handle it. If I need to
order a sub. key, I can use the name of the permanent staff member
associated
with that room. What do I do about the vault? Should I enter "vault" in
the
emp. table w/o any additional data?

5. Maybe I should cross this bridge when I get to it but I eventually will
get to the point where I will make forms and subforms. There are approx.
400
seperate keys, not including multiple copies of the same key. If I have a
combo box, is there a way to filter so that I am not looking at all 400
possiblities at once?

I am so sorry if this is too long and I'm asking too many questions at
once.
I understand that you are trying to help as many people as possible. I
have
searched and searched for answers and tried to adapt the customers/orders
format as much as possible to my situation but...I need help.

--
Aria W.

Isn't about time for you to back into hiding again? So where do you
disappear to for ten months after you ply your snake oil?

These newsgroups are for FREE peer to peer support, not a venue for low
lifes like Master Santos, AKA PCD and now, Roberta to give users false
promises of help.

Aria, Steve is not interested in helping, he is just interested in
seperating you from your money.

John...

"Mark" wrote in message
m...
Hi Aria,

You have been at this for over two weeks!!! Do you want to stop
struggling? I provide users a resource help with Access applications for a
very reasonable fee. I can design your table structure for you and provide
you a map of the tables. The map will show all the tables you need and for
each table the map will show the the name of the table, all the fields in
the table, the primary key and all foreign keys in the table. The map will
also show all the relationships between the tables and for each
relationship will show the type of relationship. You will then be able to
keep the map at your fingertips when you design the forms and reports for
the database and their associated queries. If you want my help, contact me
at .

Steve

"Aria" wrote in message
...
Doesn't me I'm not making progress. Sorry, I didn't realize their was a
time
limit on learning.
--
Aria W.


If you are enjoying your trip of discovery, take your time, there is no
rush. If you run into any problems there are many qualified people here who
are more than willing to help. Steve of course, is not one of them. His only
interest is helping himself to your money.

John... Visio MVP

"Mark" schreef in bericht m...
Hi Aria,

snipped the salvation options

Steve

Aha, now you think the OP is waiting for your 'rescue' ??
Please go see your mental coach again...


*********************************
If anyone wants to help us getting rid of Steve ??
(appropriate action will follow when there are enough complaints)
*********************************

(Earthlink and SuperNews kicked him out ?? == updated 'abuse-reporting')
http://home.tiscali.nl/arracom/whoissteve.html
Until now 5850+ pageloads, 3675+ first-time visitors

Arno R

Good one. If Steve or whoever he is had any real competence he wouldn't
need to troll here for business, and would have something other than Coming
Soon (several years now) on the Access Tips (or something) section of his
web site.

"Aria" wrote in message
...
Doesn't me I'm not making progress. Sorry, I didn't realize their was a
time
limit on learning.
--
Aria W.


"Mark" wrote:

Hi Aria,

You have been at this for over two weeks!!! Do you want to stop
struggling?
I provide users a resource help with Access applications for a very
reasonable fee. I can design your table structure for you and provide you
a
map of the tables. The map will show all the tables you need and for each
table the map will show the the name of the table, all the fields in the
table, the primary key and all foreign keys in the table. The map will
also
show all the relationships between the tables and for each relationship
will
show the type of relationship. You will then be able to keep the map at
your
fingertips when you design the forms and reports for the database and
their
associated queries. If you want my help, contact me at .

Steve



"Aria" wrote in message
...
Hi,
I'm still struggling to organize my tables and fields but I'm not as
*totally confused* as my original post; at least I hope I'm not. I'm
new
to
Access. This is my first database and I fluctuate between feeling
hopeful
I
can do this one minute and despairing that I can't the next because
I've
thought of yet another complication that I don't know how to handle. I
have
scoured the Internet and this disscussion group searching for the
answers
that I need. I found some but I am still at a loss as to what to do
about
others. I was wondering if someone would be kind enough to review my
table
structure and respond to some questions at the end. I am truly
grateful.

The information is as follows:

tblEmployees
Inactive- Yes/No
Date- Date/Time
Date Modified- Date/Time
Employee ID- (PK) Auto number Long Integer
School Data (Classification, Title, Dept. Name, Subject)- text
Personal Info (LN FN MI etc.)- text
Emergency Info - text

tblKeys
Key ID (PK)- text
Campus- text
Wing- text
RoomType(Classroom, Auditorium, Grand Master, etc.)- text

tblKeysEmployees
Key ID- composite key(FK to tblKeys)- text
EmployeeID-composite key (FK to tblEmployees)- Autonumber

tblKeysRequests
Request ID-Autonumber
Key ID (FK to tblKeys)- text
Emp. ID
Rm. number- text--I think there is a problem here. This info is part of
tblrooms.
Rm. phone- text
Date Requested- Date/time
Date Recvd.- Date/time
Date Issued- Date/time

tblRooms
Key ID (PK)-text
Room number- text
Remarks-text

tblSubs
Sub ID (PK)-Autonumber
SubLN-text
SubFN-text
MI-text
SubPhone-text
Key ID (FK to tblKeys)
Date Issued-Date/Time
Date Returned-Date/Time

If you're still reading, I have the following questions:
1. How many fields are too many in a table? I understand that Access
will
accept up to 255. I read a post that suggested that 20-30 fields may
indicate
there may be a normalization problem. I'm wondering about tblEmployees
where
there are approx. 25 fields.

2.tblRooms has a field for Rm.#; the problem is that not all rooms have
a
#.
Ex.-Storage rms., clinic, auditorium, etc. This is why I added remarks
to
tblRooms because I may have to describe a location rather than a room
#.
Will
there be a problem with this method?
One of the desired reports is a reverse directory by room #/room phone
#.
The phone # is currently in tblEmployees. Should it be moved to
tblRooms?
If
I leave it where it is, will I be able to update any queries and
reports?
I've read that multitable queries aren't updateable. We have had mass
staff
room changes right before the school year begins. It just seems it
would
be
better if the phone # was listed with tblRooms but someone told me
that's
incorrect.

3. I forgot to include the following fields: Date assigned, Return Date
and
Permission to Retain (over the summer) for Emp. Keys. Should this be
added
to
tblKeys or tblEmployees? I was told not to put *anything* into the
junction
table (tblKeysEmployees) besides the composite key already listed.

4.Keys Requests--Somethimes are request will not have a name associated
with
it. For instance, we need to request a key for the vault. I have not
accounted for this situation and don't know how to handle it. If I need
to
order a sub. key, I can use the name of the permanent staff member
associated
with that room. What do I do about the vault? Should I enter "vault" in
the
emp. table w/o any additional data?

5. Maybe I should cross this bridge when I get to it but I eventually
will
get to the point where I will make forms and subforms. There are
approx.
400
seperate keys, not including multiple copies of the same key. If I have
a
combo box, is there a way to filter so that I am not looking at all 400
possiblities at once?

I am so sorry if this is too long and I'm asking too many questions at
once.
I understand that you are trying to help as many people as possible. I
have
searched and searched for answers and tried to adapt the
customers/orders
format as much as possible to my situation but...I need help.

--
Aria W.

I have been curious as to why the posting does not appear here. Twice I
attempted to copy and paste the text. Now I am going to try copying and
pasting half of it. If that works, I'll copy and paste the second half.


OK, this post may get a bit long winded, so hopefully you won't pass
out from boredom before you get to the end.

Where do I even start with this post? Beetle, I'm in shock; I'm stunned; I
can barely think clearly; I'm horrified! When I see all that you have
done...so thorough...extensive...well thought out...patient and with great
examples. Where do I begin?

Ok, let's get into this because my comments are going to be long as well.
Bruce, I am going to make comments to you as well.
1st, I thought your post was OUTSTANDING! I'm horrified because I feel like
a student who failed the mid-term and it was *open book* with *great
teachers* who explained the concepts *in detail*!! And here you are going
over it *again*!!! I feel really bad that you two are giving so much of
yourselves to help me and I am still not picking it up. I have a book
(although at this point some of the suggestions in it are questionable), I
have read the Access Help section and printed out the ones I need to
concentrate on. As I previously stated, I scoured the Internet and read and
printed all posts that I thought will help. But know *this*, your efforts
are
not in vain. I *will* learn this and get this up and running if it's the
*last* thing I do (it may very well be with the amount of frustration I
feel)! :-)

Onward:
1:1
***
You have a 1:1 relationship between tblEmployees and tblSiteEmp. In
this case tblEmployees could be thought of as the "Parent" table and
tblSiteEmp is the "Child" table. tblSiteEmp is the child because it is
dependent upon tblEmployees. You can have an employee in
tblEmployees without a related address in tblSiteEmp, but you cannot
have an address in tblSiteEmp without a related employee in
tblEmployees.

Yes, this I understand and it makes perfect sense to me.

The rules of this relationship also state that there can be only one
child record for each parent record. Because of this, the child
table (tblSiteEmp) does not need a separate primary key.

Ok...I don't think I understood that before.

EmpID would be the PK for both tables. In tblSiteEmp it acts as both
the PK for that table and the FK to tblEmployees.

Really?!
In the parent table it can be an Autonumber but in the child table it
cannot,
because its value must be derived from an existing PK value in the parent
table.
When a new address record in entered in tblSiteEmp, an existing EmpID from
tblEmployees is inserted into the EmpID field in tblSiteEmp.

I understand. Of course, it makes so much sense *now*. I wish I had figured
that out for myself. I see that I am still having trouble with the
application of the 1:1, 1:M, M:M, PK, FK, and the parent/child relationship.
I understand the concept, I think, but what that actually means in each
table...no...not so much. I understand that PK is the ONE side and FK is the
many side but there's a disconnect as to how that works in each table. I
haven't done a good job explaining what I mean. Well, obviously you have
given me homework. I'll work on it.
2) I agree with Bruce in that an employees home phone and personal cell
phone are part of their personal information, and therefore belong
in tblEmployees, not tblPhones. IMO tblPhones should only store data
about phones that are owned and maintained by your school, which
may include cell phones *if* they are owned by the school and are
assigned to employees.

Ok, agreed; Home and employee cell belong in tblEmployees; Rm. Phone# and
district cell in tblPhones.

Bruce, I didn't quite understand your reply when you stated, "Ordinarily I
would have a one employee several phones situation. Each phone would be
associated with a single employee. The Phone table could have a
PhoneLocation
field, and maybe a TimeOfDay field for phones in shared rooms. Frankly, I
would be inclined to go with the same approach for now. If you enter the
same
number for several different employees because they are in the same room at
different times, so be it. Anything else that incorporates private phones
and
shared phones may be needlessly complex for now."

Question:
Are we dropping the M:M relationship between tblEmployees and tblphones and
inputting the phone # for each employee? 1:M? I'm a little confused. There
may be as many as 3 staff members assigned to a classroom. Bruce, I'm going
to go with our present scenario in that staff doesn't roam. Wait a minute, I
thought room phone # was going into tblLocations? In light of my stellar
performance so far in establishing relationships, I think this could get
messy. I just want to make sure I can get a directory/reverse directory out
of this.
So in this relationship tblEmployees is again the parent, and tblPhones
is the child. In this case we are allowed to have more than one child
per parent, so the child table does need to have it's own PK.

Oh my gosh, what?! *Why* are you torturing me? g This definitely
contributes to the ebb and flow of understanding...more homework.

So EmpID goes in tblPhones as a FK, not the other way around (which is how
you
have it now).

Ugh...my head hurts; I'll change it.
Another way of thinking about this is that a parent record does
not necessarily have a child, but every child record must have a parent.
Therefore, for every record in the child table, we need to know who
the parent is.

Let me "think" out loud here...o.k., more than 1 child is the many side and
you said in a previous post that the 1 side (PK) would exist in the many
side
as an FK. Did I get that right? Hmmm...I might still need to work on this
parent/child thing. I've highlighted and will keep re-reading until I master
it.

tblPhones
*******
PhoneID (Autonumber PK)
EmpID (FK to tblEmployees - long integer number)
PhoneDescription
PhoneNumber

Bruce:
I'm not following how PhoneID is a FK to tblEmpTitles.

Yeah and after re-reading what I posted; neither am I. I'm so sorry I
messed up the post and confused everyone. That's not even what I had written
on my paper. At any rate, what I did have was still wrong so... I will make
the changes to reflect the new information.

I tried sending Part 2, but still NG. Here is half of Part 2.

Now, as I said previously, the "many" side table holds the foreign key.
So, in this case, the junction table holds two FK's, which you have
done correctly in your junction table.


Finally! I did something right!

Where you went wrong is by putting EmpTitleID in tblEmployees as a FK.


....and then hope was dashed. :-(

EmpTitleID does not need to exist in *either* table.


Whoa;*what*?! trying hard not to cry I needed this explanation because
some things I was doing w/o really understanding why; simple because someone
said do this and then I would read a post that said no, do this, and the
book
would say something different. In tblKeyEmployees, I have a combo PK. That
was one of the original tables I had and yet I don't do the same thing here.

there is nothing to prevent the same title being assigned to the same
employee many times over.


There it is. What I was inadequately trying to explain earlier. I can see
this is where I'm going to get into trouble because I don't really
understand
how you would look at that and *know* it means the same title assigned to
the
same employee over and over. I'm going to have to get a handle on this; more
homework.

It is not good practice to introduce unnecessary elements into your db.


Nor do I want to; I have enough trouble already.

Still awake?..........Hello?........ Pick your head up off that desk.
Sleep
on
your own time, dammit! ;-)


....zzzz...zzzzz...huh?...what?!...I'm awake, I'm awake! (Besides I slid off
the chair and onto the floor 5 minutes ago, so there!) g

...you have two separate M:M relationships that you need to keep track of.
Don't worry, it's not as complicated as it may sound at first.


Well, maybe not for you...

tblEmployees M:M tblDepartments

[quoted text clipped - 26 lines]
EmpID (FK to tblEmployees and first part of PK - LI number)
SubjID (FK to tblSubjects and second part of PK - LI number)


I apologize to you now, Beetle, for the confusion because in my earlier post
I stated, " The other problem I had was somethng you mentioned earlier in
your sentence "..to help keep track of things." I was having trouble
tracking
what was happening; a situation that was not helped by some of the table
names I used (too many tables with the word Employee in it) and the fact
that
I kept adding notes and comments to my diagram so that I couldn't see
anything. I had spun off School Data from the employee table like we
discussed, but I had also put Emergency Info into a seperate table too.

One of those tables with the word Employee in it was tblEmpSubjects. I don't
know why I dropped it.

So in essence, your Subjects table has evolved. It is not just a way
to track subjects that are taught. Rather, it is a way to describe a
persons role within a Department.


I'm almost afraid to ask because I think I should have this down since
you've already explained but, "describe a persons role within the dept.?"
Wouldn't that info be in tblEmpDept? Let me think about this some more. If I
read it over and over; it will come.


"Aria" wrote in message
...
I posted again but for whatever reason it is not appearing here. You may
have
to go to Access Monster to read it. I see it there.
--
Aria W.


"Beetle" wrote:

OK, this post may get a bit long winded, so hopefully you won't pass
out from boredom before you get to the end.

To start with, I would like to clarify some aspects of the relationship
types.
I will cover each type separately, using your data for examples.

1:1
***
You have a 1:1 relationship between tblEmployees and tblSiteEmp. In
this case tblEmployees could be thought of as the "Parent" table and
tblSiteEmp is the "Child" table. tblSiteEmp is the child because it is
dependent upon tblEmployees. You can have an employee in
tblEmployees without a related address in tblSiteEmp, but you cannot
have an address in tblSiteEmp without a related employee in
tblEmployees.

The rules of this relationship also state that there can be only one
child record for each parent record. Because of this, the child
table (tblSiteEmp) does not need a separate primary key. EmpID would
be the PK for both tables. In tblSiteEmp it acts as both the PK for that
table and the FK to tblEmployees. In the parent table it can be an
Autonumber but in the child table it cannot, because its value must be
derived from an existing PK value in the parent table. When a new
address record in entered in tblSiteEmp, an existing EmpID from
tblEmployees is inserted into the EmpID field in tblSiteEmp. Now, when
I say that the value is inserted, keep in mind that all data entry is
done through forms, and that the form handles this process automatically.
Your users would never even see the PK value, nor should they.
In this case the tables might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblSiteEmp
********
EmpID (PK/FK - long integer number)
Address
City
State
ZipCode


1:M
***
For this example I am going to use tblEmployees and tblPhones, but with
a couple of "disclaimers", so to speak.

1) There has been some back an forth in previous posts about whether
a phone should be related to a Room or an Employee, as well as
whether the relationship should be 1:M or M:M. I don't know enough
details to answer either one of these questions, so this is only an
example
of how to set up a 1:M relationship.

2) I agree with Bruce in that an employees home phone and personal cell
phone are part of their personal information, and therefore belong
in tblEmployees, not tblPhones. IMO tblPhones should only store data
about phones that are owned and maintained by your school, which
may include cell phones *if* they are owned by the school and are
assigned to employees.

So in this relationship tblEmployees is again the parent, and tblPhones
is the child. In this case we are allowed to have more than one child
per parent, so the child table does need to have it's own PK. In this
type
of relationship the Foreign Key goes in the child table, or the table
that is on the "many" side of the relationship. So EmpID goes in
tblPhones as a FK, not the other way around (which is how you have
it now).

Another way of thinking about this is that a parent record does
not necessarily have a child, but every child record must have a parent.
Therefore, for every record in the child table, we need to know who
the parent is. So the tables might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblPhones
*******
PhoneID (Autonumber PK)
EmpID (FK to tblEmployees - long integer number)
PhoneDescription
PhoneNumber


M:M
***
You have more than one of this type, but I will use Employees and Titles
for the example. As you know, this type of relationship needs a junction
table. You can also look at this as two 1:M relationships where the
junction table is the "many" side in both relationships. So you have;

tblEmployees 1:M tblEmployeeTitles

tblTitles 1:M tblEmployeeTitles

So the combination of the two constitutes;

tblEmployees M:M tblTitles

Now, as I said previously, the "many" side table holds the foreign key.
So, in this case, the junction table holds two FK's, which you have
done correctly in your junction table. Where you went wrong is by
putting EmpTitleID in tblEmployees as a FK.

In fact, EmpTitleID does not need to exist in *either* table. In a
junction table, it is the combination of the FK's that constitute the
PK. In other words, each individual FK can be repeated many times,
but for each record the *combination* of the FK's must be unique.
The way you have it now, with EmpTitleID as the only unique identifier,
there is nothing to prevent the same title being assigned to the same
employee many times over. Now, you could leave EmpTitleID as the PK,
and create a unique index on the two FK's, but that would be ignoring
the fact that EmpTitleID is unnecessary. It is not good practice to
introduce unnecessary elements into your db. To create the proper
PK in this table, you would highlight both FK fields (EmpID and TitleID)
in design view, and then set them as the PK. For this example, the
table structure might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblTitles
******
TitleID (Autonumber PK)
TitleDescription

tblEmpTitles
*********
EmpID (Fk to tblEmployees and first part of PK - long integer number)
TitleID (FK to tblTitles and second part of PK - long integer number)

This same basic concept/structure should apply to your M:M relationship
between Employees and Classifications also.

Still awake?..........Hello?........ Pick your head up off that desk.
Sleep
on
your own time, dammit! ;-)


So now, let's move on from concepts to things that are more specific
to your application.

First, let's try to sort out the Department and Subject relationships. If
all
you were tracking was teachers this would be a bit simpler, because you
would only need to relate them to Subjects. Since each Subject would
belong to a Department, then you could determine what Departments a
teacher is related to by virtue of the Subjects they teach. You would not
need a direct relationship between the teacher and the department.

However, that obviously will not work for you because not all of your
employees teach a Subject but, presumably, they do all work in some
Department. So essentially, as I see it anyway, you have two separate
M:M relationships that you need to keep track of. Don't worry, it's
not as complicated as it may sound at first. Right now you have
tblDeptSubjects, which isn't quite right because in this case the
relationship isn't between Departments and Subjects. Basically you
have;

tblEmployees M:M tblDepartments

tblEmployees M:M tblSubjects

So the junction tables would be tblEmpDepartments and
tblEmpSubjects and the structure might look like;

tblEmployees
**********
(same fields as in the previous examples)

tblDepartments
***********
DeptID (Autonumber PK)
DeptName

tblSubjects
********
SubjectID (Autonumber PK)
SubjectName

tblEmpDepts
*********
EmpID (FK to tblEmployees and first part of PK - long integer number)
DeptID (FK to tblDepts and second part of PK - LI number)

tblEmpSubjects
***********
EmpID (FK to tblEmployees and first part of PK - LI number)
SubjID (FK to tblSubjects and second part of PK - LI number)

So in essence, your Subjects table has evolved. It is not just a way
to track subjects that are taught. Rather, it is a way to describe a
persons role within a Department. It would still include values that
describe subjects like Economics, European History, and the like, but
it would also have values like Department Chair and Custodial Staff.


Moving on again, addressing some specific things from your last post;

4) You appear to have no relationship between an employee and
the dept. they work in or the subject they teach.

What?! Please see above. I thought I had. I thought it should be in
tblSiteEmp.

I didn't notice the field in tblSiteEmp at first. I can see why you
thought
it should go there. It's because you misunderstood where the FK's go.
You thought they belonged in the "One" side table. You then probably
thought if you put it in tblEmployees, you would end up with an empty
field in the Substitute teacher records, so you put it in tblSiteEmp.
This
is actually wrong for two reasons;

1) As discussed before, the FK's don't go in the "One" side table

2) tblSiteEmp exists for one reason only. To store address information
for your full time staff. Employee names are not in tblSiteEmp, so
if you were to relate something to tblSiteEmp, you would essentially
be relating it to an address, which would be somewhat meaningless
without a name. I can see no scenario in which you would relate
anything to tblSiteEmp (other than tblEmployees, which is its
parent).

I admit I haven't resolved how I am going to work Preferred Subject or
the
Subs Credential (if they're Certificated) into the mix. I was thinking
maybe
I could just list it under Subject but that brought up other issues
that was
going to complicate things even more.

For Preferred Subject, just add a field to tblEmployees and have the
users
manually enter whatever the preferred subject is. This will add
relatively
little to the data entry process, and it will prevent you from having to
add yet another relationship to your db. If you end up with a few records
where the PreferredSubject field is empty, I think that's acceptable.

As far as the Subs credentials, that would be handled in the same manner
as the full time staff. If they have some type of credential, then there
will
be a record in tblEmpClassifications to reflect that fact. If not, there
won't
be a record. Simple.

This is where I decided to add Substitutes. It seemed to me to be an
attribute/sub-type of employee. True? Administrators can belong to both
Certificated and Admin. but I don't even want to get into that. For my
purposes, they are Administrators, period. That is of course unless you
two
present a situation where I will need to revise that (shudderplease
don't...it's getting complicated).

I agree. An Administrator is just that. Let's not add any more
complication.


Well, that's my two cents worth. Keep in mind that some of this is just
my opinion. Someone else may disagree with some of what I've suggested
because it is probably not *fully* normalized, but I think it's
normalized
enough that it would be completely functional. Once you get your head
around how the relationships work, it should start to come into focus.
Hopefully I didn't get carpel tunnel for nothing :-)

BTW - Howcome I have to put in my two cents worth, but I only get a
penny for my thoughts? g

--
_________

Sean Bailey

A bit more?

You then probably thought if you put it in tblEmployees, you would end up
with an empty field in the Substitute teacher records, so you put it in
tblSiteEmp.


Hmm...I think you're giving me too much credit although we're all aware of
my dislike for empty fields. :-(



2) tblSiteEmp exists for one reason only. To store address information for
your full time staff.


What?! When did this happen? I thought it was to store info that didn't
pertain to subs (addresses and emergency info). BTW Bruce, that's how we
ended up with tblSiteEmp because Subs aren't obligated to nor will they
disclose their address or any emergency info. I will break out in hives if I
have all of those empty fields (approx. 14-16) for *every* sub record. :-(
Just so you both understand, we aren't talking about 1 or 2 subs per day
here. We're a large school. We've had as many as 20 sub requests in a single
day; depending on what's going on (training, workshops, conferences,
illness,
etc.). There's always something going on.

For Preferred Subject, just add a field to tblEmployees and have the users
manually enter whatever the preferred subject is. This will add relatively
little to the data entry process, and it will prevent you from having to
add yet another relationship to your db. If you end up with a few records
where the PreferredSubject field is empty, I think that's acceptable.


At this point, so do I; done!



"Aria" wrote in message
...
I posted again but for whatever reason it is not appearing here. You may
have
to go to Access Monster to read it. I see it there.
--
Aria W.


"Beetle" wrote:

OK, this post may get a bit long winded, so hopefully you won't pass
out from boredom before you get to the end.

To start with, I would like to clarify some aspects of the relationship
types.
I will cover each type separately, using your data for examples.

1:1
***
You have a 1:1 relationship between tblEmployees and tblSiteEmp. In
this case tblEmployees could be thought of as the "Parent" table and
tblSiteEmp is the "Child" table. tblSiteEmp is the child because it is
dependent upon tblEmployees. You can have an employee in
tblEmployees without a related address in tblSiteEmp, but you cannot
have an address in tblSiteEmp without a related employee in
tblEmployees.

The rules of this relationship also state that there can be only one
child record for each parent record. Because of this, the child
table (tblSiteEmp) does not need a separate primary key. EmpID would
be the PK for both tables. In tblSiteEmp it acts as both the PK for that
table and the FK to tblEmployees. In the parent table it can be an
Autonumber but in the child table it cannot, because its value must be
derived from an existing PK value in the parent table. When a new
address record in entered in tblSiteEmp, an existing EmpID from
tblEmployees is inserted into the EmpID field in tblSiteEmp. Now, when
I say that the value is inserted, keep in mind that all data entry is
done through forms, and that the form handles this process automatically.
Your users would never even see the PK value, nor should they.
In this case the tables might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblSiteEmp
********
EmpID (PK/FK - long integer number)
Address
City
State
ZipCode


1:M
***
For this example I am going to use tblEmployees and tblPhones, but with
a couple of "disclaimers", so to speak.

1) There has been some back an forth in previous posts about whether
a phone should be related to a Room or an Employee, as well as
whether the relationship should be 1:M or M:M. I don't know enough
details to answer either one of these questions, so this is only an
example
of how to set up a 1:M relationship.

2) I agree with Bruce in that an employees home phone and personal cell
phone are part of their personal information, and therefore belong
in tblEmployees, not tblPhones. IMO tblPhones should only store data
about phones that are owned and maintained by your school, which
may include cell phones *if* they are owned by the school and are
assigned to employees.

So in this relationship tblEmployees is again the parent, and tblPhones
is the child. In this case we are allowed to have more than one child
per parent, so the child table does need to have it's own PK. In this
type
of relationship the Foreign Key goes in the child table, or the table
that is on the "many" side of the relationship. So EmpID goes in
tblPhones as a FK, not the other way around (which is how you have
it now).

Another way of thinking about this is that a parent record does
not necessarily have a child, but every child record must have a parent.
Therefore, for every record in the child table, we need to know who
the parent is. So the tables might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblPhones
*******
PhoneID (Autonumber PK)
EmpID (FK to tblEmployees - long integer number)
PhoneDescription
PhoneNumber


M:M
***
You have more than one of this type, but I will use Employees and Titles
for the example. As you know, this type of relationship needs a junction
table. You can also look at this as two 1:M relationships where the
junction table is the "many" side in both relationships. So you have;

tblEmployees 1:M tblEmployeeTitles

tblTitles 1:M tblEmployeeTitles

So the combination of the two constitutes;

tblEmployees M:M tblTitles

Now, as I said previously, the "many" side table holds the foreign key.
So, in this case, the junction table holds two FK's, which you have
done correctly in your junction table. Where you went wrong is by
putting EmpTitleID in tblEmployees as a FK.

In fact, EmpTitleID does not need to exist in *either* table. In a
junction table, it is the combination of the FK's that constitute the
PK. In other words, each individual FK can be repeated many times,
but for each record the *combination* of the FK's must be unique.
The way you have it now, with EmpTitleID as the only unique identifier,
there is nothing to prevent the same title being assigned to the same
employee many times over. Now, you could leave EmpTitleID as the PK,
and create a unique index on the two FK's, but that would be ignoring
the fact that EmpTitleID is unnecessary. It is not good practice to
introduce unnecessary elements into your db. To create the proper
PK in this table, you would highlight both FK fields (EmpID and TitleID)
in design view, and then set them as the PK. For this example, the
table structure might look like;

tblEmployees
**********
EmpID (Autonumber PK)
LN
FN
MI

tblTitles
******
TitleID (Autonumber PK)
TitleDescription

tblEmpTitles
*********
EmpID (Fk to tblEmployees and first part of PK - long integer number)
TitleID (FK to tblTitles and second part of PK - long integer number)

This same basic concept/structure should apply to your M:M relationship
between Employees and Classifications also.

Still awake?..........Hello?........ Pick your head up off that desk.
Sleep
on
your own time, dammit! ;-)


So now, let's move on from concepts to things that are more specific
to your application.

First, let's try to sort out the Department and Subject relationships. If
all
you were tracking was teachers this would be a bit simpler, because you
would only need to relate them to Subjects. Since each Subject would
belong to a Department, then you could determine what Departments a
teacher is related to by virtue of the Subjects they teach. You would not
need a direct relationship between the teacher and the department.

However, that obviously will not work for you because not all of your
employees teach a Subject but, presumably, they do all work in some
Department. So essentially, as I see it anyway, you have two separate
M:M relationships that you need to keep track of. Don't worry, it's
not as complicated as it may sound at first. Right now you have
tblDeptSubjects, which isn't quite right because in this case the
relationship isn't between Departments and Subjects. Basically you
have;

tblEmployees M:M tblDepartments

tblEmployees M:M tblSubjects

So the junction tables would be tblEmpDepartments and
tblEmpSubjects and the structure might look like;

tblEmployees
**********
(same fields as in the previous examples)

tblDepartments
***********
DeptID (Autonumber PK)
DeptName

tblSubjects
********
SubjectID (Autonumber PK)
SubjectName

tblEmpDepts
*********
EmpID (FK to tblEmployees and first part of PK - long integer number)
DeptID (FK to tblDepts and second part of PK - LI number)

tblEmpSubjects
***********
EmpID (FK to tblEmployees and first part of PK - LI number)
SubjID (FK to tblSubjects and second part of PK - LI number)

So in essence, your Subjects table has evolved. It is not just a way
to track subjects that are taught. Rather, it is a way to describe a
persons role within a Department. It would still include values that
describe subjects like Economics, European History, and the like, but
it would also have values like Department Chair and Custodial Staff.


Moving on again, addressing some specific things from your last post;

4) You appear to have no relationship between an employee and
the dept. they work in or the subject they teach.

What?! Please see above. I thought I had. I thought it should be in
tblSiteEmp.

I didn't notice the field in tblSiteEmp at first. I can see why you
thought
it should go there. It's because you misunderstood where the FK's go.
You thought they belonged in the "One" side table. You then probably
thought if you put it in tblEmployees, you would end up with an empty
field in the Substitute teacher records, so you put it in tblSiteEmp.
This
is actually wrong for two reasons;

1) As discussed before, the FK's don't go in the "One" side table

2) tblSiteEmp exists for one reason only. To store address information
for your full time staff. Employee names are not in tblSiteEmp, so
if you were to relate something to tblSiteEmp, you would essentially
be relating it to an address, which would be somewhat meaningless
without a name. I can see no scenario in which you would relate
anything to tblSiteEmp (other than tblEmployees, which is its
parent).

I admit I haven't resolved how I am going to work Preferred Subject or
the
Subs Credential (if they're Certificated) into the mix. I was thinking
maybe
I could just list it under Subject but that brought up other issues
that was
going to complicate things even more.

For Preferred Subject, just add a field to tblEmployees and have the
users
manually enter whatever the preferred subject is. This will add
relatively
little to the data entry process, and it will prevent you from having to
add yet another relationship to your db. If you end up with a few records
where the PreferredSubject field is empty, I think that's acceptable.

As far as the Subs credentials, that would be handled in the same manner
as the full time staff. If they have some type of credential, then there
will
be a record in tblEmpClassifications to reflect that fact. If not, there
won't
be a record. Simple.

This is where I decided to add Substitutes. It seemed to me to be an
attribute/sub-type of employee. True? Administrators can belong to both
Certificated and Admin. but I don't even want to get into that. For my
purposes, they are Administrators, period. That is of course unless you
two
present a situation where I will need to revise that (shudderplease
don't...it's getting complicated).

I agree. An Administrator is just that. Let's not add any more
complication.


Well, that's my two cents worth. Keep in mind that some of this is just
my opinion. Someone else may disagree with some of what I've suggested
because it is probably not *fully* normalized, but I think it's
normalized
enough that it would be completely functional. Once you get your head
around how the relationships work, it should start to come into focus.
Hopefully I didn't get carpel tunnel for nothing :-)

BTW - Howcome I have to put in my two cents worth, but I only get a
penny for my thoughts? g

--
_________

Sean Bailey