This chapter is from the book
This chapter is from the book
This chapter is from the book
Creating a Unique Values Query
Most business data—dealing as it does with unique customers, suppliers, products, shippers, and employees—is stored in tables that are designed to prevent duplicate records. In most cases, preventing duplicates is a straightforward matter of adding a primary key field (such as a customer account number or employee ID number), which, by definition, does not allow duplicate values. You can also add an index to any field and specify the Yes (No Duplicates) option in the table design window's Indexed property.
However, some tables are set up to allow duplicate values. For example, consider a simple table that contains only employee names and the dates on which they took customer orders. A single employee can take more than one order on a given day, so that table will have multiple records with the same data.
It's also not unusual for a query to return a dynaset that contains duplicate data. For example, suppose you put together a multiple-table query using Northwind's Employees, Orders, and Shippers tables. If you include the Orders table's OrderID in the query, there will be no duplicate records in the dynaset because OrderID is the primary key of the Orders table. However, if you don't include the OrderID field, the dynaset will have duplicate records. Figure 3.21 shows such a dynaset, and you can see that the two highlighted records are the same.
){kind=small}
Figure 3.21
This query combines the Employees, Orders, and Shippers tables and, because the OrderID primary key is not part of the dynaset, the result contains duplicate records.
If your multiple-table dynaset is returning what appear to be duplicate records, or if you're working with a single table that contains duplicate records, you can tell Access to include only unique records in the result. You do this by specifying that Access first examine the dynaset data to look for records that have the same values in all the dynaset fields, and then display only the first of those records. Because the determination whether a record is a duplicate is based on the field values, Access calls this a unique values query.
Follow these steps to create a unique values query:
-
Start a new query and add the tables you want to work with.
-
Add the fields you want to use for the query to the design grid and then set up your criteria, sorting, and other query elements.
-
Click an empty spot inside the query design window and then choose View, Properties (or press Alt+Enter). In the Query Properties window, click Yes in the Unique Values list and then close the window.
When you run the query, Access will display only unique records in the dynaset. In Figure 3.22, for example, you can see that only one of the duplicate records highlighted in Figure 3.21 appears in this unique values version of the query.
){kind=small}
Figure 3.22
This is the same query as the one in Figure 3.21, except that the Unique Values property has been set to Yes, thus eliminating the duplicate records in the dynaset.
NOTE
What about the Unique Records property in the Query Properties dialog box? This setting isn't all that useful because it applies only to a very limited case. Suppose you have two tables that are joined via a one-to-many relationship. By definition, data from the "one" table can appear multiple times in the "many" table. So if you then set up a query that uses both tables but includes only fields from the "one" table, there's a good chance the dynaset will display duplicate records.
(Why might you add two tables to a query and then not include any fields from one of the tables in the dynaset? The most common reason is that you're using one or more fields from the second table to enter the criteria for the query, but you don't need to see those fields in the result.)
To suppress the display of duplicate records from the "one" table, change the value of the Unique Records property to Yes.
Case Study: Drilling Down to the Order Details
You might know that Access 2003 has the welcome capability to view data contained in another, related table from within the table datasheet. In Figure 3.23, for example, you can see that the Customers table also includes a column of plus signs (+) on the left. Clicking a plus sign displays a new datasheet—called a subdatasheet—that, in this case, contains that customer's data from the Orders table (see Figure 3.24).
){kind=small}
Figure 3.23
When you view certain tables in the datasheet view, the leftmost column will contain a plus sign (+) for each record.
){kind=small}
Figure 3.24
Clicking a plus sign displays a subdatasheet showing the related data from another table.
Access sets up this subdatasheet capability whenever you establish a relationship between two tables. The Customers and Orders tables have a one-to-many relationship on the CustomerID field, so clicking a customer's plus sign displays the related records from the Orders table.
Notice, too, that the Orders subdatasheet also has a column of plus signs. Orders has a one-to-many relation with the Order Details table on the OrderID field. So clicking the plus sign beside an order displays the related details, as shown in Figure 3.25.
){kind=small}
Figure 3.25
Clicking a plus sign in the Orders subdatasheet displays another subdatasheet that contains the related order details.
The subdatasheet is a great feature, but it suffers from the same problems inherent in all table-based datasheet views: the subdatasheet might show more fields than you need to see, and it might not show fields you want to see (such as the extended price in the order details).
You can solve these problems by using query-based subdatasheets. Because the subdatasheets display data from a query dynaset, you can configure the query to display the data any way you want, and even include calculated columns.
To demonstrate the power and flexibility of query-based subdatasheets, this case study remakes the Customers-Orders-Order Details example to create a more useful way of drilling down into a customer's order details.
Adding a Subdatasheet to a Query
Before getting to the details of the case study, you need to know how to add a subdatasheet to a query. Datasheets and subdatasheets have the same parent-to-child relationship as linked tables. Here are the steps to follow:
-
In the query design window, click an empty spot and then choose View, Properties (or press Alt+Enter). Access displays the Query Properties dialog box.
-
In the Subdatasheet Name list, click the name of the table or query you want to use as the basis for the subdatasheet.
-
In the Link Child Fields box, enter the name of a field from the child table or query (the object you chose in the Subdatasheet Name list). This must be the field that will be related to a field in the parent (which is, in this case, the dynaset created by the query).
-
In the Link Master Fields box, enter the name of a field from the parent query. This must be the field that will be related to the field you entered in step 3.
-
(Optional) Use the Subdatasheet Height box to enter the maximum height, in inches of the subdatasheet. If you enter 0, Access displays all the records in the subdatasheet.
-
When the Subdatasheet Expanded property is set to No, Access hides all the subdatasheets and you need to click the plus signs (+) to see them; if you prefer that Access display all the subdatasheets automatically, change this property to Yes. Figure 3.26 shows an example of the Query Properties dialog box with these fields filled in.
-
Close the window.
)
Figure 3.26
To add a subdatasheet to a query, fill in the Subdatasheet Name, Link Child Fields, and Link Master Fields properties.
Working with Query Subdatasheets
The secret to working with query-based subdatasheets is to work from the bottom up. That is, you begin with the lowest level of data and create a query that displays the data in exactly the way you want. Then you move up to the next level, which will be a query based on a table that has a common field (or, at least, a relatable field) with the first table. Repeat this until you get to the topmost query.
For example, in the Customers-Orders-Order Details case, you proceed as follows:
-
Create a query based on the Order Details table. In this case study, I created a query named Order Details With Extended Prices that shows not only the details such as product, price, quantity, and discount, but also the extended price for each product, which is given by a calculated column based on the following expression, as shown in Figure 3.27:
-
Create a query based on the Orders table and include the Order Details With Extended Prices query as a subdatasheet (as described in the previous section) related on the OrderID field. For the case study, I named this new query Orders With Extended Order Details.
-
Create a query based on the Customers table and include the Orders With Extended Order Details query as a subdatasheet related on the CustomerID field, as shown in Figure 3.28.
){kind=link}
Figure 3.27 The query from the lowest level of the drill-down: the Order Details with an Extended Price calculated column.
)
Figure 3.28
The query based on the Customers table also has a subdatasheet that used the Orders With Extended Order Details query.
Figure 3.29 shows the resulting Customers query with displayed subdatasheets for the Orders With Extended Order Details query and the Order Details With Extended Prices query.
){kind=small}
Figure 3.29
Drilling down from the Customers-based query to the Orders With Extended Order Details query and to the Order Details With Extended Prices query.
From Here
-
For more about a query's Unique Values property, see "Creating a Unique Values Query."
-
For the details on creating multiple-table queries using SQL, see "Using SQL with Multiple-Table Queries."
-
To learn how to use multiple tables in a form, see "Creating a Multiple-Table Form."
-
To learn how to use multiple tables in a report, see "Creating a Multiple-Table Report."