One Form from multiple One to One related Tables question.

  • Thread starter Thread starter Bayou BoB
  • Start date Start date
B

Bayou BoB

I have 3 client tables, all with one to one relationships since there
should only be one record for each client. I have broken it down as
follows below. What I want to do is create a form to admit a client
into care. I have made a query that has all of these fields in it, and
the relationshiop between the tables is one to one, via the "ClientID"
field. I tried to make a form using a tab control, with each tab
representing one table from below. Tab1 Client, Tab 2 Client Info, Tab
3 Client Medical. This all went on the form nicely, with all the below
fields for each table on a seperate tab sheet. However I experienced
difficulty. When trying to use it, If I only entered information on
say Tab 1, the client's basic information, and then tried to close it
(A social worker may enter the basic information, and a nurse may come
along a few hours later to enter the medical information, so it needs
to be flexible enough to allow data entry on different tabs, at
different times)...I encountered an error saying that it could not
find a corresponding entry in the Client Info table and wouldn't be
able to save as a result. I noticed that it also didn't put in an
entry for the client (not even just the new ClientID number) in any
of the other related tables. It should at least put a number
automatically into the other tables to denote a new client has been
added shouldn't it? So that way you can come back and add something
for that person later on? I realize I could just stick all of this in
one big table, but I was trying to normalize the tables as much as
possible. What is my best and simplest option for making this all come
together smoothly in one multi tabbed form?

I also need a combo box to look up the new client to add information
to his file as people have time to do so (as I was saying above about
one person starting the info entering process, and someone else
finishing it at a later date). I have a query that takes ClientID,
Last Name and First Name, and calculates a full name for me in a field
called "FullName" in the query. When I try to add a combo box to this
form to look up the name of the client that someone needs to complete
adding information for, you can select a name from the list, but the
client's information does not come up on the screen. Any thoughts?
Sorry for length...this is the last portion of the project to
complete. Many MANY thanks if you have gotten this far down my post.
If I have been unclear, I'd be glad to re-clarify anything.

Kevin

Table 1 Name: Client

Fields:
ClientID (primary key, automatically assigned number, indexed (no
dupicates))
Last Name
First Name
Date of Birth
Date of Admission
Admitted From
Notes

Table 2 Name: Client Info (important info, but not accessed as
frequently)

Fields:
ClientID (primary key, datatype set to "number", indexed (no
duplicates))
Social Insurance Number
Client Type
Primary Worker
Other Agency Affiliation
Other Agency Affiliation2
Other Agency Affiliation3

Table 3 Name: Client Medical (important to our health care people who
could care less about much of the above information but need this
infor frequently)

Fields:
ClientID (primary key, datatype set to "number", indexed (no
duplicates))
Health Card#
Family Doctor
Dentist
Specialist
Diagnosis1
Diagnosis2
Diagnosis3
Diagnosis4
Eye Color
Hair Color
Distinguishing Marks
Other Concerns
 
It should at least put a number
automatically into the other tables to denote a new client has been
added shouldn't it?

No, it shouldn't. That's not how relationships work! Even a one-to-one
relationship has directionality - there is a "master" table (in this
case, it should probably be your Client table, and apparently that's
how you set it up); the other tables are dependent on having a record
in this table.
So that way you can come back and add something
for that person later on? I realize I could just stick all of this in
one big table, but I was trying to normalize the tables as much as
possible.

If you have one Entity (real-life person, thing, or event) the proper
normalization would be to have it all in one table: one entity, one
table.

I STRONGLY suspect, though, that you have some embedded one to many
relationships! Your Medical table in particular: surely a client may
have multiple medical conditions, multiple diagnoses, multiple
treatment plans? If you have a typical doctor's office checklist of
140 conditions this should NOT be modeled as a table with 140 fields;
it's instead a Many (patients) to Many (conditions) relationship,
wherein you would add a new *record* to a PatientConditions table for
each condition. What are some typical fields in your tables?
What is my best and simplest option for making this all come
together smoothly in one multi tabbed form?

IF you want to use the three tables related one to one, then base the
Form on the Client table, and put Subforms on the two tab pages based
on ClientInfo and ClientMedical. The subforms' Master Link Field/Child
Link Field properties will ensure that the ClientID gets added when
you add data to the child forms; a simple three-table join query will
not unless you tweak it just right.
 
If you have one Entity (real-life person, thing, or event) the proper
normalization would be to have it all in one table: one entity, one
table.
I STRONGLY suspect, though, that you have some embedded one to many
relationships! Your Medical table in particular: surely a client may
have multiple medical conditions, multiple diagnoses, multiple
treatment plans? If you have a typical doctor's office checklist of
140 conditions this should NOT be modeled as a table with 140 fields;
it's instead a Many (patients) to Many (conditions) relationship,
wherein you would add a new *record* to a PatientConditions table for
each condition. What are some typical fields in your tables?

So then would it make more sound or better sense then to do as you're
suggesting? Cease to create the one to one relationships and have a
client exist on one whole table....while moving the one to many
relationship fields to other tables. (ie. Diagnosis fields, of which
there are 4 of them, each based on a different class of diagnosis).
Have seperate tables for Diagnosis that are going to be used
repetitively through many clients.... Referring agencies, and other
agency affiliations have their own tables, but like diagnosis, have an
entry in the main Client table, again because each agency my have
multiple clients in the client table.... that sort of thing? As I have
yet to write the actual client portion of the database (I have been
saving that for last given it is the most complicated portion) I do
have the luxury of making radical design changes without much
consequence presently. That then simplifies it and creates a better
designed system as a whole? Many thanks. Your help is appreciated...

Kevin
 
So then would it make more sound or better sense then to do as you're
suggesting?

Without getting into more depth than I'm able to in this forum, I'd
say that it is. Otherwise I wouldn't have suggested it... <g>

Check out some of the good resources on "Normalization" at
http://support.microsoft.com and http://www.mvps.org/access; and read
up on the subject in one of the many good Access books. Having your
tables properly normalized requires some spadework at the beginning of
your project but will make your live vastly easier as you proceed. If
you're building a house, you want the foundation solid before you
start putting up walls - it's the same here.

If you've got specific questions about how to structure the tables,
don't hesitate to post back (probably in the
microsoft.public.access.tablesdbdesign newsgroup rather than here);
we'll be glad to help.
 
Back
Top