Part V: Access and Windows SharePoint Services
1138
l (^) Security: SharePoint supports users and groups of users. Users and groups may be
granted or denied access to various parts of a SharePoint Web site, and designated users
may be granted permission to add, delete, or modify the site.
l Versioning: SharePoint automatically maintains a version history of objects and data.
Changes can be rolled back to an earlier state at virtually any time. The ability to roll back
changes can be granted to individual users, and DBA support is not required.
l (^) Recycle bin: Deleted data and objects are held in a recycle bin so that they may be recov-
ered. Unlike Access, in which every deletion or change is permanent, SharePoint supports
an undo feature for its data.
l Alerts: Users and groups can be sent e-mail when specific data in a SharePoint list is
added, deleted, or changed. If granted the proper permissions, users can manage their
own alerts.
l (^) End-user maintenance: SharePoint sites are meant to be maintained by their users, with-
out the intervention of IT departments. Although SharePoint pages are not as flexible as
typical Web pages, a SharePoint developer is able to add or remove features from pages,
change fonts, headings, colors, and other attributes of pages, create subsites and lists, and
perform many other maintenance and enhancement tasks.
l Other features: Every SharePoint site includes a number of features, such as a calendar, a
task list, and announcements, that users may turn off or remove.
The ability of users to maintain a SharePoint site is a major difference between a SharePoint site
and a Web site built with a tool such as ASP.NET. The Web pages in a .NET Web site are tightly
bound to the compiled code that manages the site. A user cannot change an ASPX page because it
is stored on a Web server, and (in most cases) the code behind the page must be recompiled when
changes are made to the page’s interface.
Publishing Access applications to SharePoint
Publishing an Access application to SharePoint is a multistep process. Fortunately (as you’ll see in
Chapter 35), Access 2010 includes wizards and helpers to guide you through the process.
Because of the variety of methods and architectures that you can use when publishing to
SharePoint, reducing the process to a list of steps to perform every time you publish an Access
application to SharePoint is difficult. Chapter 35 covers some of these options in detail, so I’ll
describe only the most basic publishing process here.
In most cases, you will start with a completed, working Access application. In the Backstage area,
click the Publish to Access Services button or click the Share button on the left side of the
Backstage area (see Figure 34.1) to open the Access Services Overview area (shown in Figure 34.2).