May 12, 2013 Leave a comment
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.
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.