Typing Info Into Multiple Tables at Once

Is it possible for me to type one column of info in one table and have it
also appear in another table? I have 3 tables that have two columns the
absolute same.
Case No. & Conservatoree. I need to have these two bits of info appear in
all 3 tables, without typing it in each one. I have set up a relationship
between the 3 tables with the Case No as my Primary Key. I have typed in my
info in the major table and that info won't appear in the other two tables.
Thank you for any help you can give me.

Why? As in "why do you want to have data duplicated in multiple tables"?
What will having it duplicated allow you to do?

(hint: it is rarely necessary to duplicate data across multiple tables in a
well-normalized relational database.)

Regards

Jeff Boyce
Microsoft Office/Access MVP


"DebbieSue" wrote in message
...
Is it possible for me to type one column of info in one table and have it
also appear in another table? I have 3 tables that have two columns the
absolute same.
Case No. & Conservatoree. I need to have these two bits of info appear in
all 3 tables, without typing it in each one. I have set up a relationship
between the 3 tables with the Case No as my Primary Key. I have typed in
my
info in the major table and that info won't appear in the other two
tables.
Thank you for any help you can give me.

On Wed, 26 Nov 2008 15:48:05 -0800, DebbieSue
wrote:

Is it possible for me to type one column of info in one table and have it
also appear in another table? I have 3 tables that have two columns the
absolute same.

Then your tables are incorrectly structured.

Case No. & Conservatoree. I need to have these two bits of info appear in
all 3 tables, without typing it in each one. I have set up a relationship
between the 3 tables with the Case No as my Primary Key. I have typed in my
info in the major table and that info won't appear in the other two tables.
Thank you for any help you can give me.


Relational databases use the "Grandmother's Pantry Principle": "A place - ONE
place! - for everything, everything in its place". You can determine the
Conservatoree by storing it once, in one table, with the Case No as its
primary key, and using a Query joining this table to any other table which
contains the Case No.

If you have three tables all of which have the Case No as the primary key, you
must have one to one relationships. These are very rare; what Entities
(real-life persons, things, or events) do these three tables represent? If
each record of each table contains information about a single case, why not
have just one table with all the fields? Do you perhaps have some repeating
groups of fields, in effect having a one to many relationship embedded in each
record?
--

John W. Vinson [MVP]

I understand what you are saying. With that in mind, I would need only 2
tables. I want to have another table for billing. I don't want a table with
the name, address, attorney, conservator, and jan - dec months for billing.
This would make my table very big. Of course I could design a form to put in
the billing for just that month. Well, I guess you changed my mind. I will
try it with one table.

Thank you,
DebbieSue

"John W. Vinson" wrote:

On Wed, 26 Nov 2008 15:48:05 -0800, DebbieSue
wrote:

Is it possible for me to type one column of info in one table and have it
also appear in another table? I have 3 tables that have two columns the
absolute same.

Then your tables are incorrectly structured.

Case No. & Conservatoree. I need to have these two bits of info appear in
all 3 tables, without typing it in each one. I have set up a relationship
between the 3 tables with the Case No as my Primary Key. I have typed in my
info in the major table and that info won't appear in the other two tables.
Thank you for any help you can give me.


Relational databases use the "Grandmother's Pantry Principle": "A place - ONE
place! - for everything, everything in its place". You can determine the
Conservatoree by storing it once, in one table, with the Case No as its
primary key, and using a Query joining this table to any other table which
contains the Case No.

If you have three tables all of which have the Case No as the primary key, you
must have one to one relationships. These are very rare; what Entities
(real-life persons, things, or events) do these three tables represent? If
each record of each table contains information about a single case, why not
have just one table with all the fields? Do you perhaps have some repeating
groups of fields, in effect having a one to many relationship embedded in each
record?
--

John W. Vinson [MVP]

On Mon, 1 Dec 2008 10:03:00 -0800, DebbieSue
wrote:

I understand what you are saying. With that in mind, I would need only 2
tables. I want to have another table for billing. I don't want a table with
the name, address, attorney, conservator, and jan - dec months for billing.

Well, of COURSE you would have another table for billing. If you're talking
about fields named Jan, Feb, Mar then that's certainly incorrect. You would
instead have a Case table related one to many to a Bill table; the latter
table would have a CaseNo as a foreign key (it would NOT need the
Conservatoree or any other case information), and a BillDate field. For twelve
bills you would put in twelve records.

This would make my table very big. Of course I could design a form to put in
the billing for just that month. Well, I guess you changed my mind. I will
try it with one table.

You certainly don't need to use all one table - use two tables but use them
normalized! Use a Form based on Case, and a Subform based on Billing, and
you'll be able to see both without needing to store information redundantly.
--

John W. Vinson [MVP]

I will try that. Forms are not my thing on this newer version.

Debbie

"John W. Vinson" wrote:

On Mon, 1 Dec 2008 10:03:00 -0800, DebbieSue
wrote:

I understand what you are saying. With that in mind, I would need only 2
tables. I want to have another table for billing. I don't want a table with
the name, address, attorney, conservator, and jan - dec months for billing.

Well, of COURSE you would have another table for billing. If you're talking
about fields named Jan, Feb, Mar then that's certainly incorrect. You would
instead have a Case table related one to many to a Bill table; the latter
table would have a CaseNo as a foreign key (it would NOT need the
Conservatoree or any other case information), and a BillDate field. For twelve
bills you would put in twelve records.

This would make my table very big. Of course I could design a form to put in
the billing for just that month. Well, I guess you changed my mind. I will
try it with one table.

You certainly don't need to use all one table - use two tables but use them
normalized! Use a Form based on Case, and a Subform based on Billing, and
you'll be able to see both without needing to store information redundantly.
--

John W. Vinson [MVP]

On Mon, 1 Dec 2008 13:08:11 -0800, DebbieSue
wrote:

I will try that. Forms are not my thing on this newer version.

I haven't gotten used to 2007 yet either... but forms are ABSOLUTELY essential
to any professional application.
--

John W. Vinson [MVP]