This is a brief recap of my Philly .net Code Camp 2013.1 presentation.
Detailed information about the requirements and configuration of Access Services can be found in this TechNet wiki. It is important to note that this functionality requires the following versions of the related applications.
- Access 2013
- SharePoint 2013 Enterprise Edition
- SQL Server 2012
Access 2013 still provides the classic ‘Desktop’ databases we built over the past 20 years. The new version also includes a ‘Web App’ database which creates a SharePoint hosted app for the web front-end and a SQL Server database for storing the content. This is a huge change from the 2010 version of Access Services were the tables were converted to SharePoint Lists. SPLists provide a better scalability story than the traditional desktop database, but still have the list throttling limitations inherent in a SP List. Moving the table content to SQL Server addresses both the scalability and size issue by providing a true relational database engine to support the data. The use of SQL Server is completely transparent to the user as this communication is handled by Access Services communicating directly to SQL Server.
Access 2013 also provides some templates to get the process started. Many of the templates come in both desktop and web app versions. It is important to note as there is no switching from one version to the other after the template is chosen. There is also no upgrade path from previous versions of Access databases into the Web App database. This may be one reason why SharePoint 2013 still contains a legacy service for hosting Access 2010 web databases that come over in a content migration. Also desktop databases can contain VBA code behinds. So while the Access database artifacts all have complementary SQL Server objects, there is no analogous object for VBA code in Access 2013 Web Apps. This presents one of the limitations to the current implementation that changes are more configuration than customization via code. I think this is an area that will be improved in further releases, most likely by allowing javascript and CSS changes as opposed to c#/VB code behind files.
Let’s talk about the SQL Server component. As mentioned this must be a SQL Server 2012 database. It is also recommended that Access Services use a SQL Server instance separate from the SharePoint Farm instance. This will provide isolation for your Access Web App databases in case you need to connect to these databases through other means. A packaged web app deployed to the SharePoint Apps site creates an instance specific database each time the app is added to a site so these databases can quickly multiply. The Configuration Wizard will use the existing SharePoint Farm Database as the location for storing Access Web App databases. This can be managed in the Access Services page under Manage Service Applications in Central Admin. It is important to note that the databases created for the Access Web Apps are not included in any of the SharePoint Farm backups. These databases must be included in your disaster recovery scenarios for your environment to ensure this data is protected.
On the SharePoint side, the custom web app, once deployed to the app store and added to a site, takes on the properties of the hosted site. SharePoint permissions work on the Access Web App just like they would on a SharePoint list. Any site specific branding is also applied when viewing the Access Web App.
There is more coming on this subject as we had some good discussion and interesting questions raised during the session.
