Chapter 34: Understanding Access Services
1141
Perhaps the most important role played by Access Services is maintaining the relational nature of
the tables exported to SharePoint when an Access application is published to SharePoint.
SharePoint itself is not relational in the sense that we expect and require in a database. Although
SharePoint supports lookup columns, this ability is more a convenience to link data in one list to
another list, not to enforce referential integrity.
Access Services provides the logic required to join list data and maintain referential integrity
between lists, as long as the relationships between tables are defined before the Access application
is published to SharePoint.
Access Services uses hidden SharePoint lists to manage the formal relationships between Access
tables as the tables are migrated to SharePoint. If, for instance, you have established a one-to-many
relationship between a customers table and a sales table, Access Services manages this relationship
on the SharePoint side through entries in hidden SharePoint lists. As a result, you will not be able
to delete a customer record without first handling the customer’s sales records.
However, SharePoint does not have a “relationships” screen. Instead, as described in Chapter 35,
you use Access as the database designer to make updates to the application’s schema and resyn-
chronize the changes with the database previously published to SharePoint.
Access Services in SharePoint 2010 also provides data caching. Rather than relying on the native
ability of SharePoint to locate and deliver data, Access Services provides a middle-tier caching ser-
vice that stores data that is likely to be consumed by the application and delivers the data much
more quickly than SharePoint alone. The caching is transparent to users and developers, and no
configuration options exist for setting up the cache or modifying its parameters.
The Access Services layer filters data in a query before adding it to the cache. This means that que-
ries that include a WHERE clause are guaranteed to run more quickly and make better use of
Access Services’ caching than a query that selects all rows from the underlying table(s). As with any
database application, you should plan on using query predicates (the WHERE clause) when possi-
ble to minimize the amount of data that moves between the data store (in this case, SharePoint
lists) and the user interface.
Examining Access Web Application Limits
Access Web applications are not the best solution for public-facing Web sites, and are better suited in
departmental or workgroup environments. Certain limitations mean that the Access/SharePoint Web
option is targeted for specific situations. These limitations are discussed in the following sections.
Not public-facing
The limitations of Access Web applications are determined more by SharePoint than anything in
Access itself. For instance, SharePoint does not support anonymous access to SharePoint sites.
Users are expected to log on to a SharePoint site, using a valid user name and password
(SharePoint uses Windows Active Directory services to identify users).