Chapter 34: Understanding Access Services ..............................................................................
1137
Looking at Web Publishing in Access
Ideally, users would have fast, simple access to their data, without the constraints of large database
systems such as SQL Server. Although linking to SQL Server database tables from Access applica-
tions removes the problems caused by multiple copies of the database on different computers and
provides a high degree of database security, users often depend on database administrators for sim-
ple tasks such as developing stored procedures to sort or filter data in various ways.
Microsoft’s solution to the conflicting needs of business users and IT departments is to provide
tools in Access 2010 that allow Access developers to publish Access applications on SharePoint
sites. When you publish a properly prepared Access application to SharePoint, users benefit from
simple and easy access to their data and retain the ability to view and work with the data in either
Access forms or SharePoint lists. The data in a published Access application is centralized and
stored in SharePoint lists. The SharePoint data is secure because users must be granted permission
to use SharePoint, but after they provide their user name and password, the SharePoint data is
accessible through any Web browser. Chapter 35 covers this process in detail, and explains the
changes required in an Access application to make Access object compatible with SharePoint.
An Access application residing on a SharePoint server represents a single point of maintenance,
which is a major benefit for developers. To modify a form or report, it must be copied from
SharePoint to a local Access installation, where the changes are made. Only one developer at a time
can take out a form or report, and when the object is returned to SharePoint, all users receive the
updated object the next time they use the application.
Why SharePoint?
Many developers question why Microsoft chose to make Access Web development reliant on
SharePoint Services. If the intent is to make Access a bona fide Web development tool, doesn’t it
make sense to incorporate true Web development capabilities into Access, like Microsoft did with
Visual Studio, many years ago?
When Microsoft examined the issues involved, it quickly became clear that adding credible Web
development capabilities to Access wasn’t practical. Many of us forget that a Web site is far more
than just HTML pages. Security, performance, and data integrity issues must be considered.
For instance, Jet (or ACE, for that matter) is unsuitable as a Web database system. You cannot
coerce the multiuser, stability, and capacity requirements of a public Web site into an .accdb
database. The architecture is wrong, and making it right would require rewriting ACE for the Web
environment.
Leveraging SharePoint features
Microsoft chose SharePoint as the platform for Access Web publishing because of the significant
features built into SharePoint, including the following: