s-101
| For example, when you move a Product field to the filter area, you can display data for one product at a time. |
s-102
| Moving row or column fields to a higher or lower level |
s-103
| When a view has multiple row and column fields, the fields that are closest to the detail data are referred to as inner fields. |
s-104
| The other fields are outer fields. |
s-105
| You can switch the inner and outer fields. |
s-106
| Example of inner and outer row fields |
s-107
| 2 Outer row field |
s-108
| 2 Inner row field |
s-109
| 3 Outer field items |
s-110
| 4 Items for the inner field are repeated for each item in the outer field. |
s-111
| Adding and removing fields |
s-112
| The layout of a PivotTable view does not have to include all of the fields that are available from the underlying record source. |
s-113
| You can also remove fields that you no longer want to see from the PivotTable view layout. |
s-114
| Customizing the layout of a PivotChart view |
s-115
| You change the layout of a chart by moving the fields to predefined drop areas within the chart workspace. |
s-116
| To do this, drop areas must be shown in the chart. |
s-117
| Drop areas are displayed differently depending on the chart type. |
s-118
| For example, a series drop area is not displayed for a pie chart because pie charts consist of only one series. |
s-119
| Additionally, it is written in a style similar to an XML document using a combination of XML-like tags and HTML to create a template for a specific style of output. |
s-120
| Note that you are not required to link either a CSS file or an XSL style sheet to an XML document in order for Internet Explorer 5 (and later versions) to display the document. |
s-121
| Internet Explorer has a default, built-in style sheet that displays the XML source as a (collapsible|expandable) tree. |
s-122
| You can use style sheets to insure that the XML-based Web pages on your intranet or Website are consistent and present a uniform appearance without having to add HTML to each page. |
s-123
| About Extensible Stylesheet Language Transformation (XSLT) |
s-124
| XSL for Transformation (XSLT) is a specification that is currently under development by the World Wide Web Consortium (W3C), and supported by Access. |
s-125
| XSLT is an XML-based language that allows one XML document to be mapped, or transformed, into another XML document. |
s-126
| This provides a way of transforming an XML document's presentation information from a source format to a target format and back again. |
s-127
| Typically, a developer creates an XSL transformation file that, when applied to an XML document during export, interprets or transforms the XML data into a presentation format that can be recognized by another application, such as Service Advertising Protocol (SAP) or a custom purchase order format. |
s-128
| XSLT has many of the constructs (structures and commands) found in other programming languages which allow the developer to use variables, loops and iterations, and conditional statements. |
s-129
| This gives the developer considerable control over the output of the XML data. |
s-130
| About exporting to XML files |
s-131
| Exporting data and database objects to an XML file is a convenient way to move and store your information in a format that can readily be used across the Web. |
s-132
| In Access, you can export the data, the schema (data structure), or both, to XML files. |
s-133
| Export data to an XML file and, optionally, use an XSLT to transform the data to another format. |
s-134
| Export the data schema using XML Schema standard (XSD). |
s-135
| Export the data behind forms and reports to an XML file. |
s-136
| You can also transform the data to another presentation format using an Extensible Style Language (XSL) file during the export process. |
s-137
| You can export tables, queries, and the data behind forms or reports from a Microsoft Access database (.mdb) as well as tables, views, stored produces, functions, and the data behind forms and reports from a Microsoft Access project (.adp). |
s-138
| Exporting tables, queries, views, datasheets, forms or reports |
s-139
| You can export a database object as an XML document in several ways: |
s-140
| You can export just the data from a table, query, datasheet, form, or report into an XML file. |
s-141
| This data is saved to a file named .xml. |
s-142
| You can export just the schema (data structure) of a table, query, datasheet, form, or report to an XML schema file. |
s-143
| An XML schema file is a formal specification of the rules for an XML document, providing a series of element names, as well as which elements are allowed in the document and in what combinations. |
s-144
| If you select to save the schema as XSD, the file is saved as .xsd. |
s-145
| Note |
s-146
| When you export a table to an XML document, you can also export related tables. |
s-147
| For example, if you export a table of Customers Orders, you can also choose to export a related Orders Details table and Customers table into the same file. |
s-148
| If selected, you can also save the structure of a table, query, datasheet, form, or report into a file that describes the presentation and connection information. |
s-149
| For forms and reports, this file is saved in an XML-based language called ReportML which provides presentation data as well as a data model for creating a data access page. |
s-150
| For tables, queries-views, and datasheets, the presentation file is a spreadsheet-like template. |
s-151
| This file is saved as _report.xml. |
s-152
| In addition, when you choose to save the data as XML, you can specify that the data be transformed to a custom display format by using an existing .xsl file. |
s-153
| If no .xsl file is specified, the data is saved in standard XML format. |
s-154
| Note that if no data is selected for export then a presentation format is also unavailable. |
s-155
| What is ReportML? |
s-156
| ReportML is a 'language' developed by Microsoft and specific to Access which can be used to describe Access database objects in XML. |
s-157
| The ReportML language is made up of a set of tags that describe a form, report or data access page's properties, events, and attributes. |
s-158
| When you export data from Access to an XML file, you choose to save the structure of a form or report into a ReportML format. |
s-159
| The ReportML file can be used to convert the saved data into a data access page. |
s-160
| Well-formed documents |
s-161
| Any XML document produced by Access is well-formed, which means that it conforms to the basic rules of XML. |
s-162
| That is: |
s-163
| Each XML document must have a unique root element (an element encompassing the entire document). |
s-164
| All start and end tags match. |
s-165
| XML tags are case-sensitive. |
s-166
| For each start tag, there is a corresponding end tag. |
s-167
| Empty elements can be denoted by a special shorthand tag. |
s-168
| Again, XML tags are case-sensitive. |
s-169
| Access ReportML will not write out any empty tags. |
s-170
| Elements do not overlap. |
s-171
| In other words, start and end tag must be properly nested within other elements. |
s-172
| Certain reserve characters are part of the XML syntax and will not be interpreted as themselves if used in the data portion of an element. |
s-173
| You need to substitute a special character sequence (called an 'entity' by XML) as follows: |
s-174
| Character |
s-175
| Entity |
s-176
| The following is an example of a well-formed XML document: |
s-177
| where: |
s-178
| is a declaration that states that this is an XML document and gives the version number. |
s-179
| The declaration is optional but is recommended in any XML document. |
s-180
| is the root element which encompasses the entire document. |
s-181
| is a start tag and is an end tag which together describe an element of data, in this case, the customer's name. |
s-182
| Notice that each tag set has both start and end tags and is case sensitive, and that the tag sets are properly nested within each other. |
s-183
| Also notice the entity ' which will be transformed to an apostrophe when the data is imported by the receiving application. |
s-184
| The apostrophe has a special purpose in an XML document and can be misinterpreted if used directly in the text. |
s-185
| The converted data will be displayed as Mom's Boston Crab Meat. |
s-186
| White space can be used throughout the document to enhance readability. |
s-187
| If a schema is specified while exporting from Access, then the XML documents created are considered to be valid XML documents. |
s-188
| This means that in addition to being well-formed, the documents conform to a defined schema. |
s-189
| About exporting or copying a PivotTable view to Excel or other applications |
s-190
| If you are familiar with Microsoft Excel PivotTable reports and want to work with the data in Excel, there are two ways to accomplish this. |
s-191
| Exporting data to an interactive Excel PivotTable report |
s-192
| To view and modify the contents of a PivotTable view by using Excel, you can export the PivotTable view to Excel. |
s-193
| Preparing for export to Excel |
s-194
| Excel PivotTable reports can not display detail fields. |
s-195
| When you export to Excel, detail fields will be available on the PivotTable toolbar in Excel, but the fields won't be displayed in the report. |
s-196
| If you want the Excel PivotTable report to reflect the appearance of the PivotTable view, before you export to an Excel PivotTable report, either move all the fields out of the detail area, or hide detail data for items and cells so that the detail area is not displayed. |
s-197
| After you export |
s-198
| You might notice some differences in your PivotTable view after you export it to Excel. |
s-199
| This is because PivotTable views use the Microsoft Office PivotTable Component, and Excel PivotTable reports either do not support certain PivotTable list features, or they implement some features differently. |
s-200
| For information about differences between PivotTable lists and Excel PivotTable reports, see Excel Help. |