How best to view data from several tables?

Posted on 2008-10-31
Last Modified: 2013-12-05
I am a beginner, trying to develop an Access 2007 (.adp) "project" as a front-end to Tables stored in a SQL Server 2005 Express database.
I have a "Stock Items" table, a "Customer History" table and a "Supplier History" table. These "History" tables list each time a customer or supplier was sold (or delivered) a quantity of each stock item. The "Stock Item Code" is used to link a "host" stock record to its own records in the "History" Tables.
The two "History" tables contain "address codes" that link to other "Customer Address" and "Supplier Address" tables respectively, from which I can get the full name and other details of the customer or supplier involved.

In my main "Stock Record" Form, I would like to click on a "History" page and see a list of sales and deliveries relating to the item, sorted in date order. This page would hopefully contain a "sub-form" pulling (and mixing) records from the "Customer History" and "Supplier History" tables.

I have tried to create a "View" in SQL Server upon which to base my "sub-form" but I can't get the "JOIN" clauses to coallate all the information I need. It seems to have trouble "going off in 2 directions" to read data from two separate "history" tables linked to the central "Stock Items" table.

I have tried combining the separate "Customer" and "Supplier" history tables into a single "mixed" history table, using an "AddrKind" field to distinguish between Customers and Suppliers. This has 2 major drawbacks - I (think I) lose my "cascading" relationship that allows "histories" to be removed if a Customer or Supplier is deleted from the main address tables, and in my sub-form ("continuous" or "datasheet" view), when I try to fill out a fuller "name" field (in the On_Current event procedure), the same address name appears in all lines. Storing the "full name" of the customers and suppliers in the "History" tables would get around this, but that seems a bit unwieldy.

I could also copy the Customer and Supplier histories into a "temporary" mixed history table in the "On_current" event and also read in the full names from the address tables. The contents of this "temporary" table would be removed when the item was finished with. But this also seems a bit cumbersome and might fall apart in a multi-user environment where more than one user might want to look at a stock item at the same time.

Can anyone suggest the best strategy I should adopt? I thought this type of thing would be fairly easy using Access & SQL Server, so I hope it is just me being a bit thick.

Many thanks. Colin.
Question by:colinasad
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 5
  • 3
LVL 40

Expert Comment

by:Vadim Rapp
ID: 22850592
I would indeed combine your two tables, customers and suppliers, into one table, indicating what it is by a separate field. Cascade delete should still work as soon as there's foreign key. As for the the name, if it pertains to the parent record, then show it on the main form rather than on subform. Re, "customer address" and "supplier address", I would combine them accordingly; if customer/supplier name does not change from address to address, then it obviously belongs to the table CustomerSupplier rather than Address.


Author Comment

ID: 22851298
Thanks for your suggestions, vadimrapp1

Since posting my original question I have discovered the "UNION ALL" expression that can be used in an SQL Server "view". This appears to allow me to execute more than one SQL expression (one for customer events and one for supplier events) in my "view" and combine the results.

My concern about the "cascade" implications of combining "customer" and "supplier" events in a single table is that my client uses old numeric codes for his customers and suppliers, so it would be possible to have a customer "00001" and a supplier "00001". I thought it would be easier to keep the tables updated automatically if they were separate.

Any further comments are welcomed.
LVL 40

Expert Comment

by:Vadim Rapp
ID: 22851377
> so it would be possible to have a customer "00001" and a supplier "00001"

Make composite primary key:  id + AddrKind

As I said, you can still have separate views, and when it's better to work with customers and suppliers separately, use the view; but when you need combined view, work with the unified table.

The Ultimate Checklist to Optimize Your Website

Websites are getting bigger and complicated by the day. Video, images, custom fonts are all great for showcasing your product/service. But the price to pay in terms of reduced page load times and ultimately, decreased sales, can lead to some difficult decisions about what to cut.


Author Comment

ID: 22856302
Thanks again vadimrapp1.

I was aware of the "composite" primary key feature but do not know (to be honest, haven't tried) how to establish a "cascadable" fireign key relationship with them.
if I combine a "C" + "00001" for a customer history record and "S" + "00001"  for a supplier history record, how does Access know to delete the "C" + "00001" entries when I delete customer "00001" from the main "Customer" address table and the "S" + "00001" entries if I delete a supplier with identifying code "00001"?

I apologise that you are havining to give me tuition on what are probably fairly basic Access features, but knowing this would certainly help me.

LVL 40

Accepted Solution

Vadim Rapp earned 500 total points
ID: 22856477
table CustomersSuppliers
other data pertaining to the customer/supplier, such as name
table Orders
other data pertaining the transaction, such as date

table StockItems
other data pertaining to stock item, such as name

Primary keys are in bold.

CustomerSupplierId and CustomerSupplierType in Orders is foreign key for Id and Type in CustomersSuppliers. ItemId in Orders is foreign key for StockItems.

Note that I separated customersSuppliers into a separate table, so information pertaining to the customer/supplier (name, address etc) does not repeat in every row of the History.

As for cascade deletions, I'd think that better idea would be exactly to prohibit any deletion from Orders, or from your current History table - exactly because historical financial data needs to be kept. But it's of course your business and your choice.

Author Comment

ID: 22858788
Thanks again vadimrapp1,

I have tried to use your suggested strategy but am having a problem establishing a "foreign key" relationship between pairs of combined fields.

I have combined "AddrType" and "AddrCode" fields as a primary key in a mixed customers & suppliers "TBLAddress" table (ie "AddrType" = "C" or "S" for "customer" or "supplier", and "AddrCode" is the identifying code for a particular customer or supplier).

In my "TBLEventsHistory" table I have corresponding "HistAddrType" and "HistAddrCode" fields to identify the "owner" of the event (and a "HistUniqID" "identity" field is used as the primary key).

However, when I try to establish a "foreign key" relationship between the two tables, I get a message about a "Foreign Key Conflict" error in my "TBLAddress" table. I only have 6 records in my "TBLEventsHistory" table that are filled out with codes for existing customers and suppliers so I'm pretty sure the problem is "logical" rather than "data". I envisage that the sort of relationship I am trying to establish is between "AddrID + AddrCode" in my "TBLAddress" table and "HistAddrID + HistAddrCode" in my "TBLEventsHistory" table.

I am doing this in "Microsoft SQL Server Management Studio Express" where I maintain my SQL Server tables. In the "Design" view of my "TBLEventsHistory" table I use the "Foreign Key Relationships" dialogue box where I select my "TBLAddress" table as the "Primary key table", from which I select the "AddrType" and "AddrCode" fields. I specify my "TBLEventsHistory" table as the "Foreign key table", from which I then select the "HistAddrType" and "HistAddrCode" fields.

Am I doing this the correct way; just listing the pairs of fields beneath the table names? Do the fields I want to combine to form part of the relationship need to be "indexed" as well? I have tried doing this in my "TBLEventsHistory" table (they already form the "primary key" in my "TBLAddress" table) but that doesn't seem to make any difference.

I hope this is clear and that you can shed light on where I'm going wrong.

Author Comment

ID: 22858850
I do aplogise, vadimrapp1,

It was a "data" problem and not a "logic" problem after all. Even though I had only 6 records in my "TBLEventsHistory" table, I had deleted one of the owning address records when I had been experimenting earlier today with separate customer and supplier address tables and separate customer and supplier events history tables. I had forgotten I had done that.

That's an hour of my life I won't get back again. I hope you didn't spend too much time on my previous posting (which was only 10 minutes earlier).

Regards. Colin.

Author Closing Comment

ID: 31512048
Thanks vadimrapp.
You have revealed how multiple fields can be combined for foreign key relationships. Despite my initial "data" problems I have managed to get it working. Many thanks.

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Phishing attempts can come in all forms, shapes and sizes. No matter how familiar you think you are with them, always remember to take extra precaution when opening an email with attachments or links.
You need to know the location of the Office templates folder, so that when you create new templates, they are saved to that location, and thus are available for selection when creating new documents.  The steps to find the Templates folder path are …
In Microsoft Access, learn different ways of passing a string value within a string argument. Also learn what a “Type Mis-match” error is about.
Do you want to know how to make a graph with Microsoft Access? First, create a query with the data for the chart. Then make a blank form and add a chart control. This video also shows how to change what data is displayed on the graph as well as form…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question