Intro to databases with MS Access

There’s a sense in which almost every computer program is a database program – the sense that a computer program typically operates on a base of data. However, what the world has come to call a database package is a computer program that performs certain types of operations on sets of highly structured data records; these operations include

finding data; sorting data; “filtering” – separating records that satisfy a property of interest from those records that don’t

satisfy the property – e.g., if making a University’s Dean’s List means having a QPA of at least 3.25, from a database of student records that includes QPAs, we can determine the Dean’s list by filtering for QPA > 3.25;

Organizing data into a variety of customized reports.

Examples of databases you have probably used:

1. A library’s catalog may be thought of as a database with a record for each book in the library. A book record has fields/components/members/properties/attributes for title, author(s), copyright date, publisher, classification in either the Dewey Decimal system or the Library of Congress system, status with respect to availability (available to a new borrower, or currently checked out), etc. Before the availability of database technology, a library’s catalog would typically consist of a large card file with a 3x5 file card for each library book. This would take up a huge amount of space. This example suggests that just as word processing improves on typewriting, and spreadsheets improve on calculators, and PowerPoint and other presentation graphics software improves on slide transparencies, database represent a technological advance for the organization of large amounts of data as compared with the use of card files.

2. When you shop on the Internet, your Web browser is interacting with the vendor’s database of available products. A record for an available product might have fields for a product description, an order code, a unit price; perhaps, product reviews; a picture of the product; etc.

3. When you login to WebAdvisor, you interact with a database of student records. Typically, you only get to see your own record. A student record will have fields for your last name, first name, home address (in the database, this is probably many fields), e-mail address, local residence, home phone, local phone, fields with names and grades for all the classes you’ve taken, fields for what you owe in tuition, room and board, and other fees, etc.

Roughly, a field is a unit of information within a record. E.g., in the WebAdvisor database, a record might represent one student, with fields as discussed above.

You can start the Access program by clicking Start, All Programs, Microsoft Office, Microsoft Access 2010. Notice that when you select New Blank Database, you are immediately expected to save the database (choose its name, storage location, file format – Microsoft 2007 databases – note a 2007 database is a 2010 database) and click the Create button. This is because when you perform certain

operations in Access (including editing data), Access automatically saves your work – so Access must know when you create the database where it is to be saved.

Note the display at the left of the Access window, called the “command center” or “control center.” This serves as a menu of the sub-documents of the database. You can open one of these documents by double-clicking its representation in the command center.

The heart of an Access database is one or more “tables.” You can create a table via the Create tab’s Table button.

Notice the View button, which is found on several tabs, including Home and Fields. Clicking this button allows us to change our view of the current document in the database. A table (also, a query) has 2 views – the datasheet (a datasheet is a table or query) view and the design view. The datasheet view shows a grid, in which a row is a record and a column represents a field; a cell shows the value of a field for the record of its row. This view is used to view and edit data values. The design view is used to choose names of fields and a variety of their properties. Notice that the image on the View button shows the view you can get to by clicking the button – it shows a designer’s table when the current view is the datasheet view and a click gets you to the designer view, and it shows a datasheet when the current view is the design view and a click gets you to the datasheet view.

When we design a field, one of the properties we must choose is the field’s data type. Some of the important data types:

Text – typically used for non-numeric data such as names, titles, etc. Among the related properties is the Field Size, which for the Text data type is the maximum number of characters permitted to a value in this field. A smaller Field Size uses less memory than a larger one, but also restricts the number of characters that can be stored in the field.

A variation on the data type Text, that presents the data-entry user with a menu from which a value can be selected (often, faster and less error-prone than typing), makes use of the Lookup Wizard choice from the data type menu. You can choose Lookup wizard and then, say, choose to type in the values that are to appear on the menu.

Number – typically used for data with which we might perform numeric operations. The Field Size property for this data type offers a menu of sub-types, including the following integer sub-types:

o Byte – used for a restricted range of integer values, typically 0 to 255.o Integer – used for a restricted range of integer values, typically -32,767 to 32,767.o Long Integer – typically used for a range of values from about -2 billion to about 2

billion.o Why not always use Long Integer, then, as it offers the most freedom with respect to

the range of values that can be used? You pay a price in memory – Long Integer uses more memory than Integer, which uses more memory than Byte.

and non-integer sub-types

o Single (short for “single precision real number”) – typically implemented to store real numbers (including 0) with non-zero absolute values of about 10-37 to about 1037, with about 7 significant digits of accuracy in the sense of scientific notation.

o Double (short for “double precision real number”) – typically implemented to store real numbers (including 0) with non-zero absolute values of about 10-110 to about 10110, with about 13 to 15 significant digits of accuracy in the sense of scientific notation.

o Why not always use Double, then, as it offers more freedom with respect to the range of values that can be used? You pay a price in memory – Double uses more memory than Single.

Currency – another variant on the Number type, in the sense that values of this type can also be used in arithmetic calculations. Notice that a value for this field is typically displayed as would its analog in Excel be – with a dollar sign, commas if useful, and negative values displayed without a minus sign but with parentheses.

Yes/No – this is a data type that has 2 values, but each has 3 representations. In the datasheet view of a datasheet (table or query), a field of this type is represented by a checkbox. In this view, the values of such a field are represented by the checkbox being either checked or unchecked. When we design filters for queries, we’ll see that such a field is represented in text, using values “Yes” or “True” corresponding to a checked checkbox; “No” or “False” corresponding to an unchecked checkbox (without the quotation marks).

Consider a street address such as

175 South Muhlenberg Street apt. 27B

Should we, e.g., consider this as the value of a single field, say, StreetAddress? Or, alternately, should we consider this as making up several fields – e.g.,

175 as the value of the StreetNumber

“South Muhlenberg Street” as the value of the Street

“apt. 27B” as the value of the Apartment?

The second approach has major advantages that will become clear when we study mail merges.

If a data-entry user enters a ridiculous value, it would be nice for the database to display an error message warning the user to correct this value. We can arrange for this by using a field’s Validation Rule. In the Design view, if you place the cursor in a field, you can use the Validation Rule to specify the range of reasonable values; then, if a user enters a value outside this range, an error message will be displayed. A range of values is typically specified by one or more inequalities, in which the field is understood without being written into the Validation Rule. For example, to limit the Tuition to $70,000 or less, we could use, under Tuition, the Validation rule

<=70000

Even better: To limit tuition to the range from 0 to $70,000, we can use the Validation Rule

>=0 and <=70000

Notice that the default error message, that appears when the data-entry user violates a Validation Rule, quotes the Validation Rule in a rather technical fashion that you might not care for. If, instead, you wish to specify your own error message, you can do so via the Validation Text property (in the Design view).

The majority of students will have 0 parking tickets. For these records, it would save the data-entry user a little work if the value 0 automatically appeared in the ParkingTix field, for new records. You can arrange this by setting a field’s Default value.

When you’re processing real data (as opposed to the fictitious data we’re using in our demo), it’s extremely important that the data be entered accurately. This may be difficult if there are enough fields that a record’s identifying data (e.g., the student’s name) can’t be seen (e.g., when we edit far-right columns). Recall that in Excel, we could deal with such a problem by splitting the screen to keep identifying data in view. Access has a very different solution to this problem – the use of a “form” that focuses attention on 1 record at a time.

To create such a form: on the Create tab, click the Form button. As a result, we obtain a form that shows the data of 1 record. We can apply this form to different records via the navigation buttons towards the bottom:

Right arrowhead: “next record” Left arrowhead: “Previous record” Right arrowhead with vertical line segment: “Last record” Left arrowhead with vertical line segment: “First record” Right arrowhead with burst of light: “New (blank) record”

To use the form to edit data, you need to be in the Form View (a selection of the View button’s menu).

A record edited using a form will show up in the table that the form is based on; however, it may be necessary to close the form and the table, and re-open the table, to see the results of this editing.

There are many ways to change the appearance of the form, using the Design View (from the View button menu). Notice the sections of the form:

Form header – analogous to a page header – used for data to appear at the top of the form. Not usually used for data of a record.

Detail section – generally used to display the data of a record. Notice that many fields are represented by 2 boxes – a “label” typically used to name the field, and a textbox typically used to show the value of the field for the current record. An exception to the above: our Vehicle field is represented by a label that says “Vehicle” and by a checkbox (not a textbox).

Form footer – analogous to a page footer – used for data to appear at the bottom of the form. Not usually used for data of a record.

Beginning in Access 2007, by default, the creation of a form grouped many controls in a fashion in which they are resized and repositioned in lockstep with each other. To unlock such groupings:

Create a “group” of controls in order to apply the same operation to each member of the group, by holding down the shift key and clicking on each of the controls you want in the group.

On the Arrange tab, click Remove Layout.

To align several controls, e.g., at their left edges vertically, or at right edges vertically, or at top or bottom edges, horizontally:

Create a group of the controls to be aligned. On the Arrange tab, click the Align button and select the desired alignment from the resulting

menu.

If you are missing a field from the form (perhaps it was accidentally deleted), you can add the field by using, on the Design tab, the Add Existing Fields button and choosing the desired field(s) to be added to the form.

Although a textbox is perhaps usually used to show the value of a field, it can also be used to define a display value by a formula. You can place a new textbox on the form by clicking, on the Design tab, the textbox button, then moving the cursor to the desired position on the form and stretching the textbox to the desired size. The textbox is automatically accompanied by a label. If you don’t want this label, click on it and strike Del. The textbox is initially “unbound” to a definition of its display value. You want to define its display value by a formula. As in Excel, a formula starts with an equal sign. When you want to refer to a field of the record, use notation that encloses the name of the field in brackets (“squared parentheses”). Thus, to compute the total of tuition, room and board, and fees, we can use the formula

=[Tuition]+[RoomAndBd]+[Fees]

Other operations that can be used to alter the appearance of the form:

In the design view, on the Format tab, we can choose number formats, font colors and other font effects, and alignments.

From the Controls section of the Design tab, you can select shapes, such as a rectangle or a line, to place on the form, using the mouse to position and to size the shape.

For any selected control or group of controls, if you click the Design tab’s Property Sheet button, the Property Sheet task pane appears. You can use this task pane to edit many properties of the selected object(s). Examples of such properties include Border Style (should borders be made of solid lines, dashed lines, etc.?); Border Width (width of border lines); Border color; etc.

A fundamental organizing operation is sorting. On the Home tab (for a table), notice the buttons labeled A-Z (Ascending) and Z-A (Descending). To sort records by a field, place the cursor in the field and click the appropriate of these buttons. However, sometimes it’s desirable to sort with respect to more than one field (e.g., sort primarily with respect to last name, using first name as the secondary or tiebreaking field when two records have the same last name). E.g., we saw that Barbara Delany doesn’t necessarily

get listed ahead of James Delany when we sort with respect to last name only. Sorting with respect to multiple fields is perhaps easier to do in a query than in a table.

Finding data is one of the most important motivations for using a database. Access has a Find button on the Home tab that activates a Find operation much like Word’s, but with several important differences. In particular, it’s important to understand the comboboxes labeled “Look In,” “Match,” and “Search.”

The Look In combobox offers a menu of the choices Current Field and Current Document. The former restricts the search to the current field (the field with the cursor). The latter results in all fields being searched.

The Match combobox offers the choices Any Part of Field, Whole Field, and Start of Field. E.g., we saw that if the search string is “Drive” (without quotation marks), then, in the Street field, “Dogwood Drive” is matched when the setting is Any Part of Field, but not when the setting is Whole Field or Start of Field.

The Search combobox allows you to limit the direction of search. Choose Up if you know the desired record must be above the record currently containing the cursor; Down if you know the desired record must be below the record currently containing the cursor; All if you need to search both above and below the current record.

Sometimes, the data you wish to find is not a single record, but the set of records that satisfy some property. We “filter” a database in order to identify a set of records. The defining property is often specified by one or more comparisons that can be written in the same style as Validation Rules.

A typical filter is designed as follows. On the Home tab, click Advanced, Filter by Form. A form for the design of the filter appears. Columns are labeled for the fields of the table. Under each column to be used in filtering, specify the appropriate comparison. When the design is completed, click the Toggle Filter button or the button at the bottom (labeled Unfiltered or Filtered, according whether or not a filter is currently applied) to apply or to remove a currently-applied filter. Examples:

To select the set of students who owe at least $6,000 in tuition, under Tuition, use the filtering expression

>=6000

By clicking Advanced, Clear All Filters, any current filter is removed both from the table and from the filter design. This may be important, because failure to clear a filter leaves its design as part of the design of the next filter you might want to apply.

To select all students with home addresses in New York State (which we have represented as NY), under StateOrProvince, specify the filtering expression

NY

or

“NY”

This is an example of looking for an exact match in a Text value.

To select all students with home addresses in the USA (recall we have left the Country field blank for such addresses), use, under Country, the filtering expression

Is Null

Null is the name of a special Text constant for the Text value consisting of 0 characters. Similarly, to filter for all students with home addresses not in the US, use the filtering expression

Is Not Null

To filter for those students with first initial B we can use, under FirstName, the filtering expression

B*

or

Like “B*”

Thus, the asterisk is a “wild card,” matching any text string or substring. Similarly, the filter expression, under City, of

*e*a*

will select records in which the City is Mesa or Newfane or Seattle.

Suppose we want to select all students with last initials from D to P. We can exploit the fact text has order (the ASCII order, an extension of alphabetical order). Thus, under LastName, we can use the filtering expression

>=”D” and <”Q”

Notice the filtering expression you might be tempted to use,

>= “D” and <=”P”

is incorrect, because, e.g., “Pelczynski” > “P” in alphabetical order.

How do we design more complex filters that use the AND or OR operators to join multiple simple comparisons?

To use either of these operators in the same field, you can use the word “and” or the word “or” in a cell of the filter design. E.g., to select the students who live in New York or in Ontario, we can use, under StateOrProvince, the filter expression

NY or ONT

or

“NY” or “ONT”

To use the OR operator to combine filtering expressions in multiple fields, make use of an Or tab (a different tab) in the filter design. E.g., to select those students who owe at least $5,000 in tuition or at least $5,000 in room and board, design the filter so that on the Look For tab, under Tuition, you use the expression >=5000 and, on the Or tab, under RoomAndBd, you also use the expression >=5000

To use the AND operator to combine filtering expressions in multiple fields, make use of the same tab in the filter design. E.g., to select those students who owe at least $5,000 in tuition and at least $5,000 in room and board, design the filter so that on the Look For tab, under Tuition, you use the expression >=5000 and, on the same tab, under RoomAndBd, you also use the expression >=5000

A query is a datasheet, built from one or more previously designed datasheets (often, but not necessarily, from a table). A query may be used to filter, to sort with respect to multiple fields, and to suppress the view of fields from its data source(s). You can create a query via the Create tab’s Query Wizard or Query Design buttons; I recommend Query Design.

When you click the Query Design button, the Show Table dialogbox appears (it probably should be named “Show Datasheet”). The purpose of this dialogbox is for you to choose one or more previously designed datasheets as sources of records for the current query. For each datasheet to be used as a source of records, select the datasheet and click the Add button. Click the Close or exit button to exit the Show Table dialogbox. This brings into view a grid with labeled rows like the following:

Field:Table:Sort:Show:Criteria:Or:

Columns of this grid are used for fields you want in your query. The rows of this grid have the following significances:

Field: Name the fields you wish to use. Table: fills in automatically as you choose fields – a Table entry gives the name of the datasheet

that a field is selected from. Sort: can be used to specify fields to sort by (each, in either ascending or descending order) Show: contains a checkbox for each field. Leave the checkbox checked if you wish to show the

field in the datasheet view; unchecked, otherwise.

The Criteria and Or rows are used for filtering.

When we select multiple fields for sorting, how does Access handle the sorting? E.g., when we required sorting in ascending order for both LastName and FirstName, how did Access know to use LastName as more important (as the primary field of the sort) and FirstName as less important (the secondary field, or tiebreaker, of the sort)? Among those fields chosen for sorting, higher priority corresponds to being further to the left in the order of columns. Thus, since LastName is to the left of FirstName and both those fields were chosen for sorting, Access takes LastName to have higher priority than FirstName. Notice if we had a MiddleName or MiddleInitial field, it would also be chosen for sorting as the tertiary (3rd-most important) field of the sort, and we would have to have LastName to the left of FirstName, which would have to be to the left of MiddleName.

To use the logic of the OR operator to combine filtering expressions in different fields, make use of, say, both the Criteria and Or lines (thus, different lines) for filtering expressions. E.g., by using the design

Field: LastName FirstName Tuition RoomAndBdTable:Sort:Show:Criteria: >=5000Or: >=4000we select those students who owe at least $5,000 in tuition or at least $4,000 in room and board.

To use the logic of the AND operator to combine filtering expressions in different fields, make use of the same line for filtering expressions. E.g., by using the design

Field: LastName FirstName Tuition RoomAndBdTable:Sort:Show:Criteria: >=5000 >=4000Or:we select those students who owe at least $5,000 in tuition and at least $4,000 in room and board.

Suppose we want a query that shows the names, and only the names, of those students with unpaid parking tickets. Thus, we would filter using the ParkingTix field, but uncheck the Show checkbox for this field. Thus, the query might be designed as follows:

Field: LastName FirstName ParkingTixTable:Sort:Show: √ √Criteria: >0Or:

The resulting datasheet:

LastName FirstName

Bartirolli Rocco

Carnack Mary Jo

LaPierre KatherineThus, the ParkingTix field was used for filtering, but is not shown in the datasheet view of the query. Note the above illustrates that data from a datasheet can be copied into a Word document – as a table, so all of Word’s table-editing power is available to you.

Note on a homework assignment: several students calculated net income values and entered them into the table, rather than having a textbox with an appropriate formula in the form. This is a bad idea, for several reasons:

If you work in this fashion, you’re servant to, rather than master of, the database. Why should you calculate for the software what the software can calculate for you?

You waste a lot of memory working this way: A net income cell for each record in the table, instead of a single formula in the form.

You waste a lot of your own time, performing these calculations and entering their values. Recalculation – if, say, a Salary value changes, a formula would recalculate the net income; a net

income cell in the table would not automatically recalculate, so either you have to take the time to do it yourself and re-enter the new value, or else leave the net income as incorrect.

More filtering:

To select all students who do have a vehicle registered and who have unpaid parking tickets, the relevant parts of the query design:

Field LastName FirstName Vehicle ParkingTix…Criteria Yes >0

This illustrates that we use “Yes” or “True” (without quotation marks) to select records that show a checked checkbox; “No” or “False” (without quotation marks) to select records that show an unchecked checkbox.

To find the records of students whose home address is in the US, we can design a query using a filter, as shown below:

Field LastName FirstName Country…Criteria Is Null

Recall “Is Null” is a filter expression for records with a null string (string of 0 characters) in the filtered field. Similarly, “Is Not Null” (without quotation marks) is a filter expression for records with a non-null string (string of more than 0 characters) in the filtered field.

To query for students with the word “Street” in the name of their street, we can design a filter including the following:

Field LastName FirstName Street…Criteria *Street*

It’s often useful to have multiple tables in a database, and to establish “relations/relationships” between tables. For example, we will add a College Data table to our database with some basic information about the university’s colleges.

The notion of a primary key is useful in establishing relationships. A primary key is a field that is not permitted to have 2 records with the same value. E.g., if our Students table had a StudentIdNum field, it could be a primary key, since no 2 students should be permitted to have the same ID number. In our example, we let the College field of the College Data table be a primary key. We also introduced a College field in the Students table, and set it up for the data-entry user to present a menu of the values taken from the College field of the College Data table. This also creates a relationship between the two tables, specifically between the fields of these tables that share a name. This can be illustrated by clicking, on the Database Tools tab, the Relationships button; as a result, a display with a polygonal line between College of College Data and College of Students, appears.

Why we create relationships can be illustrated through an example. We see in our Students data that we have a student named Mary Jo Carnack who is in the Hospitality college. It follows from the College Data table that Mary Jo’s dean is Dr. Gary Praetzel. This is a conclusion reached by combining data from

the two tables. Human intelligence does this easily; when the tables are related as we have done, Access can reach the same conclusion.

The relationship established by the Lookup Wizard isn’t as strong as it might be. A stronger relationship is the “one-to-many” relationship, which is capable of certain error-checking that the relationship set up by the Lookup Wizard is not.

(We can delete an existing relationship by clicking its polygonal line on the Relationships tab and striking Del.) A one-to-many relationship is established as follows.

If necessary, close the tables you are going to put into a relationship. One of the fields being related must be a primary key. This field is dragged and dropped to the

other field in the relationship. As a result, the Edit Relationships dialogbox appears. Check the checkbox labeled Enforce Referential Integrity. This sets up the error-checking

mentioned above. Click the Create button of the dialogbox.

As a result, a polygonal line appears joining the related fields, with a “1” at the “one” side of the relationship (the primary key) and the ∞ symbol at the “many” side of the relationship. The idea here is that one record from the table with the “one” side of the relationship is now related to, perhaps, many records of the table from the “many” side of the relationship. E.g., since a record in the College Data table represents a college, and a record in the Students table represents a student, our one-to-many relationship represents the fact that one college has many students.

This also explains why one of the related fields must be a primary key. Suppose, in our example, the College field of College Data were not a primary key. Then we could have multiple records in this table with the same College entry. This would do violence to the concept of one-to-many.

Suppose we want to design a query to filter for those students with home addresses in the US, and list the corresponding dean for each student. The relevant part of the query design would appear:

Field: LastName FirstName DeanLName DeanFName Country…Criteria: Is Null

Because we have created the relationship discussed above, Access correctly matches each student with his/her dean.

A common use of a database is to extract data and arrange it in a variety of ways not represented in datasheets, often including the calculation of useful information such as summary statistics (totals, averages, maximum and minimum values). In Access, such a document is a “report.”

A report is created from the Create tab. Multiple buttons appear in the Reports section of the tab for the creation of a report; I recommend the Report Wizard. This starts a process of the following steps:

1. Choose the datasheet(s) that are to be sources of data for the report, and the fields from the chosen datasheets that the report should use.

2. (If your report is based on more than 1 datasheet, you are asked, “How do you want to view your data?” Depending on which datasheet you choose, some grouping may take place.) Choose (if desired) appropriate (additional) grouping levels. Grouping is a form of sorting, in that the groups that you choose are listed in a natural order. E.g., if we were to group by Gender, then the records would form Female and Male groups. All the Female records would appear consecutively, and all Male records would appear consecutively; Female records would appear before Male records, as the groups appear alphabetically; within each group, its records appear segregated from the records of other groups.

3. Choose, if desired, to sort records by as many as 4 fields, each in either ascending or descending order. If the report has grouping, then choosing to sort at this step will result in the records of each group being sorted accordingly. If multiple fields are chosen for sorting, the 1st field is primary; 2nd field is secondary; etc. Also, if the report has grouping, the Summary Options button appears. This allows us to display summary statistics in a group footer, for each group and for any numeric field.

4. Choose a layout – for an ungrouped report, I recommend the Tabular layout as best-looking; for a grouped report, Stepped. Also, you can choose between Portrait and Landscape orientations.

5. If you use a pre-2010 version of Access, at this point, choose a “style” for the report (like choosing a “theme” in PowerPoint) – background patterns, font properties, etc.

6. Choose a title for the report; also choose whether to (pre)view the report or to continue designing the report.

From the preview, you can click the Close Print Preview button to go to the report’s Design View, which should remind you of the Design View of a form. As in a form, we can introduce calculated controls; move and resize controls. Thus, a report combines the power of a query and a form in important ways.

Notice the sections:

Report Header and Report Footer – for data to appear at the beginning (respectively, end) of the report. A common use of the Report Header is for a title for the report.

Page Header and Page Footer – for data to appear at the beginning (respectively, end) of each page of the report. So, if your report extends over multiple pages, data in the Report Header (respectively, Footer) appears only at the top of the first page (respectively, at the end of the last page), while data in the Page Header (respectively, Footer) appears at the top (respectively, bottom) of each page. A common use of the page header is for column headers.

Detail section – specifies how each record is to be displayed. Notice that many fields are represented by a label in the page header (serving as a column header) and a textbox in the Detail section to show the value in a field.

In a grouped report, it’s often desirable to have a group header and a group footer. These are named for the grouping field. E.g., if we group by Gender, these are called the Gender Header and Gender Footer, respectively.

Formatting properties are handled as they were in the design of a form. E.g., to change the format of the calculated control to Currency, go to the Property Sheet (when the textbox of this control is selected) and choose the Format to be Currency.

The placement of a calculated control in the design of a report has a powerful effect on how the formula of this control computes. If the textbox of this control is in the Detail section, its formula is applied to each record individually. If the textbox is place, e.g., in the Report (group) Footer, then its formula is applied to all records of the report (respectively, group). Such calculated controls are typically used for calculating summary statistics such as totals (using SUM function), averages (using AVG function – unfortunately, the average function does not share the name of its analog in Excel), maximum value (using MAX function), minimum function (using MIN function). E.g., to compute and display the total of the tuition owed by all students, we place a textbox in the report footer with the formula

=SUM([Tuition])

Other functions, familiar from Excel, are available. These include the ROUND and the IF function. E.g., to display the average number of parking tickets, rounded off to 1 decimal place, we can place, in the Report Footer, a textbox with the formula

=Round(Avg([ParkingTix]), 1)

Notice also that the report in which we used this formula used a query, not a table, as its source of records. Any datasheet(s) may be used as data sources for a report.

We have already seen one way in which Access data can be integrated into a Word document – data from a datasheet can be copied and pasted into a Word document. Two other methods of integration of Access data into a Word document will be discussed.

How do we make an Access report part of a Word document. A direct copy-and-paste doesn’t work. If you attempt a direct copy-and-paste, you will get what appears to be a copied datasheet, e.g.,

Have vehicle & tix

LastName FirstName ParkingTix Text9 Text10 Text11

Delany Barbara 1 Tuesday, December 07, 2010 Page 1 of 1 1.7

Carnack Mary Jo 4 Tuesday, December 07, 2010 Page 1 of 1 1.7

Pelczynski Matthew 1 Tuesday, December 07, 2010 Page 1 of 1 1.7

Delany James 2 Tuesday, December 07, 2010 Page 1 of 1 1.7

LaPierre Katherine 1 Tuesday, December 07, 2010 Page 1 of 1 1.7

Chelsea Brittany 1 Tuesday, December 07, 2010 Page 1 of 1 1.7

Instead, you can use the following indirect method, in which the report is “exported” – saved, in a file format that isn’t Access’ usual file format; then, “import” the saved report file into Word.

The export process:

On the External Data tab, notice the Export section of the ribbon. The More button has a menu with a Word selection.

Clicking Word begins the process of exporting (saving) the file as a Rich Text Format (RTF) file, which isn’t Word’s “native” format, but is a format that Word can read.

The data thus saved can be imported into a Word document as follows:

Open the saved RTF file in Word. Copy its data into the other Word document where you want the data to appear, as shown

below.

Have vehicle and tix

LastName FirstName ParkingTix

Delany Barbara 1

Carnack Mary Jo 4

Pelczynski Matthew 1

Delany James 2

LaPierre Katherine 1

Chelsea Brittany 1

Average parking tix 1.7Thursday, December 09, 2010

Note if you’re not careful, you may find you have copied some undesirable data. E.g., you might have copied page numbering data that is incorrect or inappropriate in the destination document. If this has happened, delete the unwanted data.

Another form of data integration between Access and Word is “mail merge,” in which we prepare a “template” or form document in Word to be modified by individualizing the form according to the data of a datasheet, creating a document for each record. A mail merge is created as follows (all the steps described below use the Mailing tab).

1. Click the Start Mail Merge button. Choose Letters from the resulting menu.2. Click the Select Recipients button. Choose Use Existing List from the resulting menu to begin a

process of choosing the database file and its datasheet that is to be the source of records for the mail merge.

3. Edit the template. Wherever you want to merge a field value into the template, click the Insert Merge Field button and choose the desired field.

4. By clicking the Preview Results button, we can see how the individual merge documents appear. Notice the navigation buttons that can be used to move among the records, merging the data of

any record into the template. Notice that the Preview Results button is an on/off switch – by clicking again, we return to editing the template.

5. The Finish and Merge button has a menu, one of whose selections is Print Documents. This choice causes all the merge documents to be printed.