how to combine two tables into one table

  • Thread starter Thread starter newbie arty
  • Start date Start date
N

newbie arty

i would appreciate some help.

I need to combine two tables into one table. there is one field that is in
common in both tables. I have set up a relationship between the two, but then
what? how do i "see" the new table?

I am trying to combine two tables (table 1 "customer name" and "address",
table 2 "customer name" and "item bought"). the common field is "customer
name", but in table 1, i have two listings for the same "customer name", work
and home address. How can I combine the tables so that "customer name", "item
bought", "work address", "home address" is combined into one table?

I NEED some HELP! My boss is breathing down my neck!
 
newbie said:
i would appreciate some help.

I need to combine two tables into one table. there is one field that is in
common in both tables. I have set up a relationship between the two, but then
what? how do i "see" the new table?

I am trying to combine two tables (table 1 "customer name" and "address",
table 2 "customer name" and "item bought"). the common field is "customer
name", but in table 1, i have two listings for the same "customer name", work
and home address. How can I combine the tables so that "customer name", "item
bought", "work address", "home address" is combined into one table?

I NEED some HELP! My boss is breathing down my neck!
Click to expand...

Don't let him get away with it. Access is powerful and rewarding, but
the best of us need time to learn it. You need training or at least a
good book, and time to absorb it. Otherwise you _will_ fail where you
_should_ succeed. Personally, I like the video training from Lynda.com
(monthly fee), but here are some other good resources:

===
Free samples from Lynda.com on table design:
http://www.lynda.com/home/Player.aspx?lpk4=31001 (A2007)
http://www.lynda.com/home/Player.aspx?lpk4=13150 (A2003)

Microsoft tutorial on table design:
http://tinyurl.com/ms-table-design-tutorial

Jeff Conrad's resources page:
http://www.accessmvp.com/JConrad/accessjunkie/resources.html

The Access Web resources page:
http://www.mvps.org/access/resources/index.html

Roger Carlson's tutorials, samples and tips:
http://www.rogersaccesslibrary.com/

A free tutorial written by Crystal:
http://allenbrowne.com/casu-22.html

A video how-to series by Crystal:
http://www.YouTube.com/user/LearnAccessByCrystal

MVP Allen Browne's tutorials:
http://allenbrowne.com/links.html#Tutorials
====

One at a time, or you'll go up in smoke!

Look at the top three links on table design. It's usually far better to
have a numeric "key" field to link tables. In a one-to-many
relationship, you simply include the key field from the "one" record
(customer) as a "foreign key" field in the "many" records (item bought).
So "Item bought" contains a reference to the customer id.

Concentrate on getting table design right first, and everything else
will be much, much easier.

HTH

Phil, London

Then you create a query to combine the information, and the output of a
query initially looks just like a table.
 
Huh? "Having separate columns for work and home is what's known as
'encoding data as column headings"

While in theory it might sound good, but every field name describes
the data. FirstName and LastName are encoding data in column
headings.

The only downside to a WorkAddress and HomeAddress is you can't have a
third (Snowbird address, for instance), and you'll be wasting some
space in rows that don't have both addresses. The upside is not
having to do more joins to get addresses.

Bryce-Cobb is great and all, but it's not a requirement, and sometimes
breaking those rules are permissable.


Chris
 
Back
Top