[For Access 2010, 2013, and 2016, go to the lesson Application Part .]
Before you can create relationships between tables, you need to have another table, of course. You already created one table manually so this time you will use a template.
Access provides some templates called Table Templates (Access 2007) and Application Parts (Access 2010, 2013, and 2016) to get you started with common types of tables, like Comments, Contacts, Users, Tasks, Issues.
This lesson covers how Access 2007 uses a table template. Previous versions of Access had a table wizard with more sample tables.
Rarely will the template be exactly what you want! It can still be helpful. You can always make changes in Design View afterwards.
The next lesson shows how Access 2010, 2013, and 2016 use Application Parts to create a table with matching forms and reports.
Access 2007 stores the templates and application parts in the AppData folder.
C:\Users\<USERNAME>\AppData\Roaming\Microsoft\Templates\Access
Unfortunately, the AppData folder is hidden by default.
To see it, change your Folder Options to show hidden folders.
Folders Options dialog > View tab > Hidden files and folders section > Show hidden files, folder, and drives
You can also store templates and application parts in one of the folders where Access is installed. The path below is for English versions of Access, which use the folder 1033. Different languages use a different number.
C:\Program Files\Microsoft Office\Templates\1033\Access\
It is easy and usually painless to add or delete records from a table. But, changing the design of a table that already has records can be more of a problem. It depends on what kinds of changes you make. Let's look at some of the complications.
Increasing Field Size can create a problem for large databases. Each record will need more storage space, even if the field is blank. That can enlarge the whole database more than you expect.
Example 1: Reduce field size safely
In the Star Wars Collectibles table, the field size for the field Condition allows up to 50 characters. The values in
this field come from a Lookup list: Mint, Excellent, Good,
Fair, Poor. The longest value you can chose is the word "Excellent,
which has 9 characters. You could safely change the length of the Condition field to 9. You would not lose any data. If you decided later
to add other values to the list, you might need to increase the field's size.
Example 2: Reduce field size and lose data
The field HowAcquired also allows up to 50
characters. The longest entry for this field that is actually used in the
records is "Bought retail", which has 13
characters. (You must count spaces also.) If you reduce the field size to
9, some entries will lose those last 4 characters. That's a "whoops!" You
really want to avoid throwing away your data!
Example 3:
Available but not used
You must look carefully at what the choices are, not just what you see in the records. For the field HowAcquired, one of the choices is "Bought at auction", which
has 17 characters. No record is using this value yet. Looking at the
records, you would not know that you need at least 17 characters. You
cannot reduce the field size to the 13 needed for the existing data after
all.
Example 4: Predicting the future
The field ItemName allows 50 characters but does
not have a list to choose from. How many characters do you really need??
The longest entry now has 27 characters. But what about the future? You must be a prophet to know how long future entries might be!
Better to leave this kind of field with lots of space.
Sometimes changing a field's type is no problem. Sometimes it is disastrous. The data for that field may be cut short or even completely lost. Some changes are just not allowed at all. Designing your tables right the first time works better!
Things to consider about changing Field Type:
Problem: Not allowed to
change a field's data type
Cause: The field is part of a relationship with another table.
Solution: Delete the relationship first in the Relationships window [Database Tools ribbon tab > Relationships], make your changes, then
recreate the relationship. But be careful that the new data type can be related to the field in the other table.
![]() |
Step-by-Step: Use Table Template (2007) |
![]() |
What you will learn: | to create a table using a template to edit a field's name and a property to create a form and enter records to attach a photo to use the Lookup Wizard to see Lookup properties of a field to use a Lookup field to delete a field to repair errors in form and report caused by deleting field to view subdatasheet in related table |
Start with: mytrips-Lastname-Firstname.accdb from a previous lesson
The Trips table has a memo field TravelAgent for information about the travel agent. You must enter this data for every trip, even if you used that travel agent previously. It would be better to have that information in its own table instead. If you use the same travel agent again, all the information will be there, waiting for you. If you need to update an email address or phone number, you can change it in one place instead of having to find all of the trip records that show that agent and edit each one.
Access has a template that will create a table with fields for standard contact information, like a mailing address, phone numbers, email address, as well as the parts of the agent's name.
You will be making changes that will remove data. Be sure to make a backup first!
Click the button Table Templates to open the list of templates.
Both Access 2007 and 2010 have just a few templates: Contacts, Tasks, Issues, Events, and Assets. In Access 2007 these templates create a table with some standard fields. In Access 2010, some of these also create related forms and reports.
A new table, Table1, opens in Datasheet View with fields already created.
Scroll horizontally to see all 18 fields. These are the basic fields that you need for contact information. BUT... the properties of these fields may not be quite right for you.
New Table Name: When you save your changes to a table created this way, you will be offered the chance to rename it. Table1 is NOT a good name!
Name the table Contacts.
This is not my favorite name for this table, but it will match what Access 2010 and 2013 do when you choose the Application Part named Contacts. Access 2010 and 2013 create a whole set of queries, forms, and reports.
Happily, we will not be duplicating all of those in this lesson. We are just trying to learn what the 'automatic' features of Access actually do.
You can change the properties of the table that the template created. Some changes can be done in Datasheet View. Other changes need to be done in Design View.
Let's start by changing the name of a field. The field ID has a name that might cause trouble later if you create another table with the template. It is a good idea for the ID fields in each table to have different names, like ClientID, OrderID, ScoreID, TaskID.
Type ContactID as the new name and press the ENTER key.
The field name is accepted.
Notice, the other column headings include a space, like First Name.
Other changes you can make in Datasheet View:
Switch to the Design View of the Contacts table.
The new name ContactID shows here.
The template created field names with spaces.(Access 2010 handles this a bit differently.) That looks great in the Datasheet View and in forms and reports that use the field name as a label, but it makes things more complicated for writing SQL queries and doing programming for the database. Most database designers use field names which do not have spaces.
Happily, you can have it both ways. You can use field names without spaces and still see column headings with spaces. The Caption property is part of the solution. You will change one field's properties to demonstrate how it works.
Click on the field First Name and look at the value for the Caption property (at the bottom of the window).
It's blank.
When the Caption property is blank, the actual field name shows as the column heading in a datasheet or as the field name label in a form or report.
Change the field name at the top to FirstName, with no space.
Change the Caption value to First Name, with a space.
Before we can use the Contacts table, it needs some records. So your next job is to create an autoform for this table to use to enter the records. Why not just type directly in the datasheet? There are 18 fields but you don't have data for most of those fields. It would take a lot of side-ways scrolling to create records in the datasheet.
Click the Save button
on the Quick Access Toolbar and name the new form ContactDetails.
The title in the form header does not change to match the tab title. That's fine.
Enter the following records. Many fields will be blank for
now.
(Remember that these are not real people, the companies are not a real
companies, and the email addresses are not real either!)
You can use the TAB key to move from field to field or just click on the field you want to edit.
FirstName | Jorge |
---|---|
LastName | Martinez |
Country/Region | USA |
CompanyName | World Travel Inc. |
Title | Agent |
WorkPhone | 615-555-1234 |
EmailName | jmartinez@worldtravelinc.net |
To attach a photo: The Attachments field can hold one or more attached files. A photo of this person would be the obvious first choice. But you could also attach files, like the job offer letter, contract, pay stub, or other documents.
Navigate to the resource files that are part of your local copy of these lessons or where you downloaded those resources, and find the file martinez.jpg.
Be careful to select the correct version of this file. The resource files contain a much larger BMP version for lessons that use older versions of Access. You want the JPG version.
Click on OK.
The dialog closes and the photo appears in the record.
This form does not show off the picture very well!
How can you fix that?
Switch to Design View.
Now you can add more records to practice your navigating and typing skills.
Copy
previous value: You can copy the value "World Travel Inc." into later
records by using the key comb CTRL + ' (the apostrophe) when your
cursor is in the field CompanyName. This key
combo copies the value of the field in the previous record into the current record. Of course, once you enter a record that has a different name in the Company field, this tip will not be helpful!
FirstName | Hector |
---|---|
LastName | Chavez |
Country/Region | Argentina |
CompanyName | World Travel Inc. |
Title | Agent |
WorkPhone | 555-9876 |
EmailName | hchavez@worldtravelinc.net |
Attachments | chavez.jpg |
FirstName | Sheila |
---|---|
LastName | Landers |
Country/Region | Australia |
CompanyName | World Travel Inc. |
Title | Branch Manager |
WorkPhone | 5554-8890 |
EmailName | slanders@worldtravelinc.net |
Attachments | landers.jpg |
FirstName | William |
---|---|
LastName | Gardner |
Country/Region | Argentina |
CompanyName | World Travel Inc. |
Title | Agent |
EmailName | bgardner@worldtravelinc.net |
WorkPhone | 555-9876 |
Notes | Nickname = Bill |
Attachments | gardner.jpg |
Evaluate: Which is easier for this table - using a form or entering data directly in the datasheet?
Did you make many mistakes in typing in the data?
Was the data given to you in the best order? Not really! That was done to show you how useful it is for the order of fields on the form to match the order that you receive it.
Sometimes you need to change the order of the controls on a form to match the order that the data comes to you. Sometimes you can adjust the data first so that the order you see it matches the order on the form.
The reason we created a separate table for Contacts was to use those values in a Lookup field in the Trips table. A Lookup field lets you pick from a list instead of having to type in a value.
The advantage is that it guarantees that you use the same value for the same agent. For example, William Gardner has the nickname Bill. Without a Lookup list, you might put in Bill for his first name one time and William another time. Sorting and filtering would not treat those names as the same.
The awkward part is that you must first add a new person to the Contacts list before you can pick them in the Trips table.
Now that the Contacts table has some records, let's create a Lookup field in the Trips table. Then you can see how such a field might be helpful and how it might present problems.
Open the original Trips table in Design View.
You already had a Memo type field with a very similar name, TravelAgent, with no space in the name. That space makes it an entirely different field. The Memo field holds the travel agent's name and contact info. You will remove one of these fields shortly to avoid confusion.
In the first page of the dialog, keep the default selection, "I want the lookup column to look up the values in a table or query."
If you had a small list of possible values that only make sense for this one table, you might want to choose "I will type in the values that I want".
Click the Finish button.
A message box appears to remind you that the table must be saved before a relationship can be created. Did you know that you were trying to create a relationship??
Click on Yes.
The wizard sets the data type to Number and fills in the properties on the Lookup tab for the new field.
If you use the wizard, you don't have to know what all these properties are that are on the Lookup tab! That's sweet.
Click the down arrow to open the Lookup list for this cell.
All of the agents you entered in the Contacts table are showing.
No more guessing about spelling! Once the data is in the Contacts table, you can just pick from a list for a record in the Trips table.
Point of Confusion: Field Data Type does not match Lookup list entry
Remember from the Design View, the new Travel Agent field has Number data type. But the drop list shows a name, not a number. How can that work?
Explanation: The wizard created a simple Lookup list that shows only one value but stores the related primary key value, ContactID. Surprise! Nothing in the interface tells you that what you see is not what is stored!
In fact, a Lookup list can display several fields, for example Lastname, Firstname, and Middlename, to help you choose the right entry, but the table can only store one value. The value that is stored does not have to show in the drop list at all! Now that's helpful but more than a little confusing!
Warning: Lookup Fields on a Table
Many database designers avoid using Lookup fields on tables. It is easy to forget that what you see in the table (like a name) may not be what is stored in that field (like an AutoNumber). Joining tables together using fields of different data types makes a mess when you try to create subforms and subreports. It can be hard to figure out where the problem is!
Let's look at what the wizard created for the Lookup list for Travel Agent.
In the bottom pane of the window, click on the tab Lookup.
Many properties are filled in now.
Display Control shows how the field will display, as a Combo Box, List Box, or Text Box. A combo box can show several fields to help you pick.
Row Source is a query that is written out in SQL. The results of this query form the Lookup list. The next properties control what columns in the query results will show in the Lookup list and what value will be stored.
Bound Column tells which column from the Row Source query will be saved in the Trips table. It is usually the first column, but does not have to be.
Column Count tells how many columns there are in the drop list.
Column Widths sets the width for each column in the drop list. A value of 0" here means that the list will use the width of the column itself. If the query has several columns, you usually want to set each width separately, like 0",0.5", 0.33",1".
List Rows sets the number of rows to show before using a scroll bar.
List Width sets the overall width of the list. This needs to be larger than or equal to the total of the column widths.
Later we will look more closely at the properties shown here.
Set the Travel Agent for the Ireland trip to Martinez.
Set the Travel Agent for the Italy trip to Chavez.
As you edit a record, a pencil icon appears beside the record at the far left. The record is dirty, meaning that you have made a change that has not yet been saved.
Point of Confusion: When is a change to a record saved?
Changes to records are not saved automatically until you move on to a different record. Just changing to a different field in the same record does not save the change.
To save changes without leaving the record, use the Save button on the Quick Access Toolbar or
the Save Record button on the Home ribbon tab.
Now that you have selected travel agents in the new column Travel Agent, do you need the original field TravelAgent (no space)?
You lose the comments about the trips arranged through a company hosting the convention. Only the name and company and email address are in the Contacts table. Not much of a loss! You could even add an entry in the Contacts table, like No Agent, to cover the trips without a travel agent.
So removing the old column has some important consequences. It's better to get the fields right at the beginning!
Because the TravelAgent field was deleted, one of the text boxes in your Trips AutoForm now shows an error, #NAME?. This code means that Access is looking for a named object that it cannot find. Either the object has been deleted or renamed or the name is misspelled. In this case, you deleted it!
Next you will fix the forms to refer to the new field. The same method applies to reports also. For this lesson the goal is to show you how awkward it can be to change tables after other objects have been created based on those tables. Plan well first!
In later lessons you will learn how to insert controls yourself and how to use a Control Wizard to set up the control.
Open the Trips AutoForm.
The TravelAgent text box
shows an error code, #NAME?.
In many cases you could just edit the Source property for the box.
In the table datasheet, the new Travel Agent field used a combo box so you could pick a name instead of a ContactID. But if you edit the Source property for the text box in the existing form, you do not get a combo box. Unexpected.
There is a simple work around. You will re-create the form to get the text box you need and then copy/paste it to the existing form. This lets Access do the heavy lifting for creating the combo box.
To correct a report, you can use the same method. The AutoReport, however, uses a control without an attached label while the Report Wizard uses controls with attached labels. So you should use the Report Wizard again to get a control that you can copy and paste.
To correct a report, you can use a similar method. Use the Report Wizard to create a temporary report, which will automatically include the new field. Then copy and paste the new control to other reports. Do not use the AutoReport for this. It does not include a label for the field.
Check for formatting issues: Be careful to check what pasting a control did to the way your form or report prints. A wide control can automatically widen the form or report so that it won't fit on one page any more. A tall control might change what fits vertically on a page.
Open Trips Report Wizard by double-clicking it in the Navigation pane.
A Parament dialog opens. What is that?
Access cannot find the field that you deleted. It is asking you to provide a value.
You now have two tables in a One-to-Many relationship. One record in Contacts is connected to Many records in Trips. The table on the One side (Contacts) will show a subdatasheet of the related records from the Many side (Trips). A relationship must be in place for subdatasheets to be available.
Open the Contacts table again.
A tiny + in a box, , shows at the left of each record because this table is on the One side of a One-to-Many relationship.
Click on the beside the record for Martinez.
A subdatasheet appears below the record and shows the records of the two trips that Martinez handled.
The subdatasheet does not show the column Travel Agent because that is the field on which the tables are joined. Remember that this Lookup field in the Trips table actually stores the ContactID value, even though you see a LastName.
Unfortunately, the subdatasheet does not show the name of the table that the record comes from. If you know your tables well, you will recognize the TripID field as the primary key for the Trips table.
Expand the subdatasheet for each of the other agents.
Chavez and Gardner show one record in the subdatasheet.
The record for Landers shows a blank record in the subdatasheet. There are no trips in the Trips table yet for which Landers was the travel agent.
Having several subdatasheets showing can make a table very hard to read. It is not normally a good plan to work directly with the table. Forms are much easier to use for data entry and review.