A Microsoft Office (Excel, Word) forum. OfficeFrustration

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.

Go Back   Home » OfficeFrustration forum » Microsoft Access » General Discussion
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Adding a primary key



 
 
Thread Tools Display Modes
  #1  
Old October 30th, 2008, 01:24 AM posted to microsoft.public.access
5ifthcitizen
external usenet poster
 
Posts: 1
Default Adding a primary key

I am having trouble adding a primary key and creating linking tables. When I
try to add a primary key, and go back to the datasheet view it tells me that
i have duplicate information. This happens with a couple different tables:

1. A purchase table that I want the primary key to be purchase # but each
purchase # can have multiple order #s. So I have duplicate purchase #s
because of this. Is there a way to set the purchase # as the primary key
without deleting the order # column? Somebody suggested using a query that I
could turn into a table but I don't know if that would work or how it would
work.

2. An order table that I want the primary key to be order # but each order #
can have multiple inventory #s. I moved the inventory #s into a separate
linking table where I put order # and inventory # as the primary key. But the
order table still has duplicate order #s so it won't let me use order # as
the primary key. How can i set order # as the primary key in the order table
and get rid of the redundancy?

Any help is appreciated, Thanks.

  #2  
Old October 30th, 2008, 02:47 AM posted to microsoft.public.access
Rob Parker[_3_]
external usenet poster
 
Posts: 173
Default Adding a primary key

Your problems are arising because you haven't quite got a handle of exaclty
how relational databases with normalised data work. You seem to have the
concept of using a primary key from one table as a foreign key in another
table, but you're missing some of the detail points.

You need (for the data you've described - there may be other related data
that you'll also have in existing table, such as Customer data) three
tables - which you've got.

tblPurchases should contain only data relating to a specific purchase -
things like PurchaseDate, Customer, etc. It should have a PurchaseID as its
primary key, and it should NOT contain an Order field, because there can be
multiple orders. This is a one-to-many relationship.

tblOrders should contain only data relating to a specific order. It will
contain (at the bare minimum) both an OrderID field, which will be its
primary key, and a PurchaseID field, which is the foreign key to a record in
tblPurchases; the table will contain multiple records for each purchase. It
will NOT contain a field for InventoryItem.

Similarly, tblInventoryItems should contain only data relating to a specific
item for an order making up part of a purchase. It will contain only data
related to a specific InventoryItem, with an InventoryID as its primary key,
an OrderID field as a foreign key to a record in tblOrders, and other fields
for the item (NumberRequired, Cost, ...); there will be multiple records in
this table for each Order.

With those three tables, you can set up a query to show all the data for
every purchase, by including all three tables, and joining (with Outer
joins - click on the join line in the query design grid and select 'Show all
records from ... ' as appropriate) the PurchaseID fields between
tblPurchases and tblOrders, and the OrderID fields between tblOrders and
tblInventoryItems. You can also set up a form with two nested subforms,
linked on the same keys in the Master-Child fields, to allow easy entry of
all data for a single purchase.

If you have existing redundant data in tblPurchases and tblOrders, you will
have to remove that before you can set PurchaseID and OrderID as the primary
key fields for those tables, respectively.

As a side point, I find the concept of three levels for this data a little
strange - I see little difference between a purchase and an order. But I'm
probably missing something vital in your overall data structure.

If you want an example of this, check out the sample Northwind database
which comes with every version of Access that I'm aware of (and if you
haven't got it, you can download it from the Microsoft Office site).

HTH,

Rob


5ifthcitizen wrote:
I am having trouble adding a primary key and creating linking tables.
When I try to add a primary key, and go back to the datasheet view it
tells me that i have duplicate information. This happens with a
couple different tables:

1. A purchase table that I want the primary key to be purchase # but
each purchase # can have multiple order #s. So I have duplicate
purchase #s because of this. Is there a way to set the purchase # as
the primary key without deleting the order # column? Somebody
suggested using a query that I could turn into a table but I don't
know if that would work or how it would work.

2. An order table that I want the primary key to be order # but each
order # can have multiple inventory #s. I moved the inventory #s into
a separate linking table where I put order # and inventory # as the
primary key. But the order table still has duplicate order #s so it
won't let me use order # as the primary key. How can i set order # as
the primary key in the order table and get rid of the redundancy?

Any help is appreciated, Thanks.



  #3  
Old October 30th, 2008, 02:51 AM posted to microsoft.public.access
Arvin Meyer [MVP][_2_]
external usenet poster
 
Posts: 2,310
Default Adding a primary key

You're building spreadsheets not a database. There is only 1 purchase order,
but there can be many orders associated with it.

PO table with 1 PO number - PK

Order Table with 1 Order Number - PK
Many PO#s - FK
Many Inventory #s - FK

Inventory Table
Inventory # - PK

That's the way it should work.
--
Arvin Meyer, MCP, MVP
http://www.datastrat.com
http://www.mvps.org/access
http://www.accessmvp.com


"5ifthcitizen" wrote in message
...
I am having trouble adding a primary key and creating linking tables. When
I
try to add a primary key, and go back to the datasheet view it tells me
that
i have duplicate information. This happens with a couple different tables:

1. A purchase table that I want the primary key to be purchase # but each
purchase # can have multiple order #s. So I have duplicate purchase #s
because of this. Is there a way to set the purchase # as the primary key
without deleting the order # column? Somebody suggested using a query that
I
could turn into a table but I don't know if that would work or how it
would
work.

2. An order table that I want the primary key to be order # but each order
#
can have multiple inventory #s. I moved the inventory #s into a separate
linking table where I put order # and inventory # as the primary key. But
the
order table still has duplicate order #s so it won't let me use order # as
the primary key. How can i set order # as the primary key in the order
table
and get rid of the redundancy?

Any help is appreciated, Thanks.



  #4  
Old October 30th, 2008, 03:45 AM posted to microsoft.public.access
Anthos
external usenet poster
 
Posts: 88
Default Adding a primary key

It might be worthwhile running a find duplicate query on the tables,
and try and find the duplicate fields that you are trying to set as
primary key.
Orders should be related to Purchases.
So you are going to need to create a table that has your orders,
then a table that has purchases, but with a field that relates back to
the orders table.

Does this make sense?

Regards,
Anthony Moore
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 07:23 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.