Adding a primary key

[5ifthcitizen]

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.

 

[Rob Parker]

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

 

[Arvin Meyer [MVP]]

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.

 

[Anthos]

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