Microsoft heavily invested in the new Microsoft Access 2013 application
model to reduce barriers that may otherwise prevent SMEs from creating
business applications. By leveraging the on-premise model of SharePoint
2013 and SQL Server for respective front- and back-end hosting, Access
2013 dramatically increases application manageability and scalability
for Access-based business applications. By leveraging the hosted app
model and relying on Office 365 to host the front end of the app and
SQL Azure to store the data, the reach and scalability of Access
applications increases significantly.
1. On-Premise Architecture
When leveraging a local SharePoint 2013
installation for publication and sharing of Access web apps, SQL Server
2012 provides the back-end functionality, whereas SharePoint and its
Access Services service application provide the user interface and
security. Figure 1 describes the Access Services architecture.
Although the Microsoft Access Office 2013 client
communicates via SOAP protocols, the web front end relies entirely on
RESTful services. Both web and desktop clients communicate to the load
balanced SharePoint web front ends that host the Access Services data
and design APIs.
NOTE Unlike
most of the rest of SharePoint 2013 service applications, the Access
Services data and design APIs are private and are not development
targets outside of the use of the Microsoft Access 2013 client.
Access Data Services (ADS) contains the session,
cache, and data access layer responsible for extracting data from the
SQL Server back end. The Access Services design APIs, responsible for
retrieving only visual elements, bypass the ADS and directly connect to
the SQL Server back end.
For each Access Services application, a new
application database is created on the Access Services Application
Database Server. This new database contains the new app’s data, views
(forms), queries, and macros. By default, the Access Services
Application Database Server is the same SQL Server that is used by
SharePoint, but a new database server can easily be configured on
Central Administration’s Manage Service Applications page to enforce a
distinct separation of concerns. Only one Access Services Application
Database Server is available per Access Services service application at
a time.
NOTE An
important consideration when activating Access Services in an
on-premise environment is an organization’s disaster recovery and data
retention policies. An environment with open access to Access 2013 web
apps can produce a large number of new databases quite rapidly!
2. Hosted Architecture
The hosted architecture for Access
Services leverages Office 365 Small Business Premium or Enterprise
editions and SQL Azure to scale upward to a theoretically infinite
number of users and to contain a theoretically infinite amount of data.
Beyond the changes to an Access web app’s reach, there are no
functional differences in the architecture (refer to Figure 1
in the previous section) and that of an Office 365 hosted app beyond
the potential difficulty in connecting reporting tools to the hosted
database.
3. Upgrade Considerations
As mentioned previously, Access 2013
desktop applications have not changed — existing ACCDB database
applications continue to function. However, Access Data Projects (ADPs)
are no longer supported due to incompatibilities with SQL Azure. ADPs
have been replaced with the new web-based Access app. Microsoft’s
guidance for ADP developers is as follows:
- Convert the ADP to an Access app by importing existing tables into
a new Access app. This causes new forms to be automatically generated.
- Convert to a linked desktop database by converting the ADP application to an .accdb format.
- Create a hybrid application by importing data into an Access app
(hosted on SQL Server/SQL Azure) and link to the newly stored back-end
data via a .accdb client application.
- Upgrade to a .NET application and leave Microsoft Access as a platform behind.
4. Database Components
Databases can contain several types of
components, including tables, queries, views, reports, and macros. This
section will examine all of them in more detail.
4.1 Tables and Queries
Access 2013 web apps leverage the entirely new back
end of SQL Server or SQL Azure. This is new compared to the Access 2010
model for Access Services, where all data was stored in SharePoint
lists. Now pause for a moment to consider a few of the implications of
this change, as shown in Table 1.
TABLE 1: Access 2013 Versus Access 2010
| ACCESS 2013 WEB APP BENEFITS |
ACCESS 2010 WEB APP BENEFITS |
| SQL Server and SQL Azure are both much faster and more scalable than SharePoint lists. |
All data is stored in a SharePoint site’s lists (provisioned by Access 2010 automatically when the application is created). |
| Data in dedicated SQL databases is accessible by a wide array of self-service BI tools, such as Excel and Crystal Reports. |
Data hosted by a single site reduces the total number of databases created/required. |
Although the management overhead for the number
of databases definitely increases with the new model, Access 2013,
complete with its dedicated web app databases, is more flexible than
the previous version.
A level of translation is required to understand how Access objects are stored in SQL Server. Table 2 identifies a number of key vocabulary terms in each database environment.
TABLE 2: Access 2013/SQL Server 2012 Vocabulary Map
| ACCESS OBJECT |
SQL SERVER OBJECT |
| Table |
Table |
| Query |
View |
| Parameter Query |
Table-Valued Function |
| Standalone Data Macro |
Stored Procedure |
| Table Event Data Macro |
Trigger |
| Validation Rule |
Check Constraint |
Any table created in Access will be stored in the
SQL Server database with the same name as in Access. Similarly, a
table’s fields will be identically named in Access and SQL Server. The
data types leveraged by Access do not match those of SQL Server
exactly, so Table 3 has been provided as a reference.
TABLE 3: Access/SQL Data Type Map
| ACCESS DATA TYPE |
SQL SERVER DATA TYPE |
| Single line of text |
nvarchar(1−4000, MAX) |
| Multiple lines of text |
nvarchar(1−4000, MAX) |
| Number |
Float |
| Number |
Int |
| Currency |
Float |
| Date |
Date |
| Date/Time |
datetime2(6) |
| Time |
Time |
| True/False |
Bit |
| Image |
varbinary(MAX) |
Each table created in an Access web app is available in the Tile Pane on the left side of the browsing user’s page. Figure 3
displays Invoices, Projects, Employees, and Clients as navigation
options representing the source tables and the views associated with
each. However, opening the application with the Access desktop client
reveals that several tables are not displayed in the web browser.
Tables in the Tile Pane can be hidden or moved up and down, but if a
tile in the Tile Pane is deleted, the table and all associated views
are also deleted. If a tile is hidden, the backing table schema and
associated views can still be modified. This is typically done to
enable macro-based access to views which would otherwise be hidden.
Access leverages queries to join multiple tables
together for purposes of targeted data discovery or data aggregation.
Access leverages a SME-friendly visual query builder to develop a
persisted mechanism to access the wanted data. This query is stored in
SQL Server as a view or a table-valued function, depending on whether
the query requires any parameters. The name of the SQL Server object
matches the names in Access. Figure 2 shows an Access query from the Microsoft sample Customer Billing and Time Tracking application.
To access the SQL Server instance behind an
Access web app, navigate to the Access client’s Backstage, and click
the Info option to view the server name and database name associated
with the published web app. In the event of an Office 365 published
Access web app, the database will be hosted on a SQL Azure instance. The SQL Server view for the previously referenced Access Query is:
CREATE VIEW [Access].[AmountOutstanding]
AS
SELECT
SUM[Total Invoice Amount].[ExpenseCost],
[Total Invoice Amount].[HoursCost],
[Invoices].[Misc Other Cost]
FROM
[Access].[Invoices]
LEFT JOIN
[Access].[Total Invoice Amount]
ON
[Invoices].[ID] = [Total Invoice Amount].[ID]
WHERE
[Invoices].[Status] <>"Paid"
