A lot of casual Access users don’t realize the immense differences between SharePoint Access 2010 Web Services and Access 2013 Web Apps.   Access 2010 Web Services actually has a lot more features and is grander in scope than Access 2013, but it also has it’s limitations (and reporting never fully worked on Office 365 or BPOS) so it was scrapped and completely redesigned as Web Apps for SharePoint/Access 2013.   Basically Access 2010 Web Databases are dead in favor of Access 2013 Web Apps.  Hopefully this post will help inform you about their differences and help you pick which type of Access Web Database works best for your business.

The Power of Access Services 2010

The awesome thing about SharePoint Access Services 2010 is the way that you can easily build one database entirely in Access and as long as you keep passing the web compatibility checker, you can publish from this one file and have all the power of a hybrid application.  All your web forms, client reports, and client forms are all contained in one file that is hosted on Sharepoint.  It has built in support for working offline from Sharepoint and resycncing when you connect again online and inherently supports multiple concurrent users.  The power of the hybrid access database seems to have been too grand of an idea because it’s complexity is very demanding on SQL reporting services and was never something that worked on Microsoft old Business Productivity Online Standard Suite or the first iteration of Office 365.  Whether it was the processing requirements of the Access 2010 hybrid application, Sharepoint list architecture or just the simple fact that they could never get SQL reporting services to work, Microsoft decided to abandon this Web Database design for Access 2013 in favor of the Access 2013 Web App.  Access Web Databases

Unlike the 2013 web app which requires you to build an entirely new Access Application, Access 2010 Web Databases let you tweak an existing database to be Sharepoint web compatible  so that you can publish them online.  This means that if you have an older database with a bunch of useful client forms and reports, you can still get the entire file backed up and working online and while these client forms won’t work in the web browser, users will still be able to sync changes and use them if they open the database in Access.  You also have the benefit of being able to supplement your Access database with browser based forms and reports as you build them in your 2010 app.  Of course 2010 has it’s downsides as well.  It does not allow the use of VBA code and as we’ve stated earlier, Microsoft has abandoned this idea of a hybrid Access application in favor of the easier to host model in 2013.

Technical differences between Access 2010 Web Databases and Access 2013 Web Apps

The big change between these two technologies is the architecture and where the data is stored.  Both 2010 web databases and 2013 web apps require SharePoint (although different versions)  However, 2010 stores the tables and application in a custom SharePoint list type, while 2013 stores them in SQL Server tables.  This change in architecture means that 2010 web databases are completely incompatible with 2013 web apps.

If you create a 2010 web database there is no upgrade path to Access 2013.  You cannot convert a 2010 web database to a 2013 web app. You can easily migrate your data (table structure and data) from a 2010 web database to a 2013 web app, but the application (forms, reports, etc) will all have to be rebuilt from scratch.  That’s pretty much the problem with Access 2013 web apps to begin with.  You have to pretty much start from scratch building all of your forms/reports in Sharepoint 2013.

Both  require SharePoint Access Services, but 2010 uses Access Services 2010 while 2013 requires Access Services 2013.  These services are very different and incompatible. However, you can have both Access Services 2010 and 2013 running on the same SharePoint site so you can host both access 2010 web databases and 2013 web apps alongside each other.  Lucky for you this is exactly what Access Hosting does with its Access Services 2010 and 2013 offering!

Access 2013 Web Apps

So the bad news is that if you’re interested in building an Access 2013 App, you’re pretty much starting from scratch (other than saving your data and tables).  You will have to build every new form and query for your 2013 Access Web App.  Another setback is that Access 2013 does not allow for any reporting to be conducted in the browser – all reporting requires Access 2013 to be installed on a person’s computer and connected to the SQL table storing your Access Web App via ODBC.  Here’s a helpful post about how to connect your web app to an Access 2013 desktop frontend.

If you’re starting a new Access project though, it makes sense to use the most up to date software and if you are an experienced Access Developer there’s a lot of tricks that you can do to use Access 2013 Web Apps to add browser functionality to an already robust app. By creating a client/desktop Access 2013 frontend and connecting via ODBC you can utilize VBA code and other more advanced functionality and while this functionality isn’t available in the browser you at least have the benefit of all being connected and using the same raw data and tables.

If you’re interested in testing Access 2010 Web Databases or Access 2013 Web Apps, Access Hosting offers a free 30 day trial on servers that are running both services.  Plans include 10 users and are only $99/month.  Additional users and storage can be added to any of these base plans.