Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 271
  • Last Modified:

How best to view data from several tables?

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.
  • 5
  • 3
1 Solution
Vadim RappCommented:
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.

colinasadAuthor Commented:
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.
Vadim RappCommented:
> 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.

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

colinasadAuthor Commented:
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.

Vadim RappCommented:
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.
colinasadAuthor Commented:
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.
colinasadAuthor Commented:
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.
colinasadAuthor Commented:
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

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 5
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now