Part V: Access and Windows SharePoint Services
1136
On the CD-ROM
This chapter uses the database named Chapter34.accdb. If you haven’t already copied this file to your
machine from the CD, you’ll need to do so now. You’ll also need access to SharePoint Server 2007 or 2010 to
experiment with the data-sharing techniques described in this chapter. Earlier versions of SharePoint support
limited data sharing with Access but do not support updating linked SharePoint lists from Access.
Explaining Managed Applications
Access has long been relegated to a role as a workgroup and departmental database development
system. In spite of its outstanding user interface and report tools, Access’s reliance on a database
file that can be corrupted or lost due to hardware failure or accidentally (or purposefully) deleted
has made Access a hard sell in many environments.
Traditionally, IT departments are charged with maintaining a company’s mission-critical database
systems. These systems — whether implemented as SQL Server, Oracle, DB2, or another server
database — require professional management, including careful design, periodic backups, and
maintaining user and group permissions. The objectives of large-scale database systems are to
ensure the availability and integrity of the data.
The objectives of departments and business units (even small businesses), on the other hand, are
flexibility and access to data. Time is money, and waiting for an IT department to develop a user
interface or a new report in a development tool such as Visual Studio.Net can be a costly. Many
business units prefer using Access because of its ability to quickly turn user requirements into bona
fide, completed applications.
The problem comes when a business unit wants to store mission-critical data in an Access data file
on a file server or (worse) on a user’s desktop or laptop computer. Without proper management, it
is easy to lose data due to a hard disk crash or a stolen laptop.
Furthermore, without careful data synchronization, different copies of a database can exist in mul-
tiple locations. As a result, Access reports can’t be trusted because no one is sure whether a report
reflects the state of the company’s data.
There is a trade-off between an expensive, large, carefully managed application such as a .NET
Windows or Web form application running on top of SQL Server and a smaller, lighter, and more
agile application built with Microsoft Access. Even when an Access application is built around data
stored in SQL Server, providing access to the data through a Web browser is difficult at best. In
most cases, users must work with SQL Server data through a LAN and depend on SQL Server data-
base administrators (DBAs) to provide permissions to the data and other support to the Access
front ends as needed.
Managed applications (such as server-based database systems) offer many advantages to businesses
and organizations. However, these same businesses and organizations also benefit from the flexibil-
ity and agility of unmanaged applications written with Microsoft Access.