Part V: Access and Windows SharePoint Services
1156
This technique works fine with Access 2007 and SharePoint 2007. Access is able to move tables to
SharePoint and link back to the Access application, and SharePoint easily accommodates an Access
application as an item in a document library.
Publishing to SharePoint option
The option described in the preceding section has a few problems. Foremost, perhaps, is the fact
that users must copy the Access application to their desktop before they can work with it. When
dealing with a large .accdb file, the copy process may take a few minutes. Also, nothing prevents
users from copying an editable version of the .accdb file and making changes to it on their desk-
top. This means that the application may be damaged by a well-meaning user who tries to improve
the application by moving things around or renaming a database object.
What is really needed, then, is a SharePoint deployment technique that essentially eliminates the
.accdb file. If users have no access to the database file, they are left working with the user inter-
face and logic provided by SharePoint. Ideally, a copy of Access (even the runtime) doesn’t need to
be installed on the user’s computer, and the application is run instead in a Web browser.
Understanding publishing to SharePoint deployment
The next deployment option is, perhaps, the most significant new feature in Access 2010. In the
following example, an entire Access application is published to SharePoint. Specifically, the Access
application is published to Access Services running within SharePoint. All the forms, reports, and
other database objects in the Access application move into SharePoint, preserving the investment
in the Access application. Tables are converted to SharePoint lists (as in the preceding example),
and other Access database objects are converted to SharePoint analogs. Queries, for instance, are
converted to SharePoint workflow objects, because workflows incorporate the logic necessary to
select and transform data in SharePoint lists. Forms are expressed as SharePoint Web pages, and
macros and VBA code are translated to JavaScript. (Using JavaScript enables the pages to be viewed
in virtually any Web browser.)
The user works with the Access application from within SharePoint. The tables, queries, and
underlying elements are hidden from the user and are handled by Access Services in SharePoint.
All forms are expressed as Web pages, and reports are implemented as SQL Server Reporting
Services (SSRS) reports. Any user (with proper SharePoint credentials) can access the application
through a Web browser, and the Access runtime is not needed on the user’s desktop.
You, as the developer, retain a special copy of the Access application on your desktop. Although
the master definition of the application resides on SharePoint, you make changes to the applica-
tion, including tables, queries, forms, reports, and code, on your desktop and synchronize the
changes with SharePoint.
The publishing to SharePoint technique is different from the deployment techniques used in previ-
ous versions of Access and, frankly, requires some adjustment. The first time you see a familiar
