locked
Migrating Access 2010 web App to Access 2013 web App RRS feed

  • Question

  • We have an Access 2010 web application (Office 365/Sharepoint tables). We use client front ends to access the data as the web forms don’t provide the required function. End users only see user forms - there’s no direct access to the underlying objects. The main benefits that we get from the current implementation are:

    • Data sharing across multiple locations
    • Ease of distribution of software changes (there’s 1 main developer - me)

    We took this approach before Access 2013 came along with a different Architecture for Access Web apps. We’re now looking at whether we should change and migrate to the Access 2013 Web App architecture. If we did we’d lose the ease of distribution of software changes but I think that we would gain in other ways: improved security(?); database performance (via Azuure instead of Sharepoint tables); longer term development path(?). Note that I still think that we’d want to retain our front end client as I don't think that the web front end will provide the functionality that we need.

    I would appreciate feedback on the above.

    Assuming that the feedback encouraged the migration then I’d like to test the approach. Do I simply need to install a single copy of Office/Access 2013 for myself to do this, ie. does the backend Office 365/Sharepoint/Azure infrastructure automatically support the creation of Access 2013 web apps or are there some ‘backend’ account settings required.

    Also, if all of the above was positive, would we need to upgrade our all of Desktops to Office 2013 to run or could we get away with running the client app as execute only ie. could this coexist with Office 2010 on the desktops.  This would avoid rollout of Office 2013 and related re-education of the user base in Office 2013.

    Friday, March 20, 2015 1:00 PM

Answers

  • You can certainly gain performance and scalability by using Access 2013, since as you note it uses SQL server.

    However, be MUCH warned, as in many cases using SharePoint tables and how Access 2010 (or 2013) works with SharePoint tables can often run absolute circles around SQL server.

    Keep in mind that because you not “really” using any real feature of web publishing, then:

    You can jump to Access 2013 and CONTINUE to use the tables on SharePoint. So the “SharePoint” table feature DOES NOT require web publishing. It just “so” happens that Access 2010 web publishing sends the data up to SharePoint tables. However “up-sizing” the data to SharePoint is a feature of BOTH Access 2010 and 2013 support. In fact this feature been around since Access 2003! (but 2010/2013 is required for good performance).

    The other major difference is web publishing for Access 2013 ALWAYS sends the data to SQL server. As noted, some significant tweaking of applications may be required to obtain good performance over the internet – often MORE tweaking then the using SharePoint tables you have now. And the connection is MUCH more robust when using SharePoint tables.

    So you could migrate your data to Access 2013, and re-publish those tables. You would then link your front ends to SQL Azure, and not be using SharePoint tables.

    Last but not least:

    Access 2013 web publishing does NOT support the auto update and download feature you are using. However LONG before the web came along I adopted code to “update” the users front ends. So for some, this “auto update” feature is not a big deal. And I always preferred to distribute a compiled accDE so users cannot change things (so once again, the auto update feature of 2010 web is not a big deal for me).

    Since you “only” using Access web services and web publishing to to download the VBA front ends, then it quite easy to “get off” that feature and "dump" Access web services in this case.

    So Access 2013 does not have an auto update, but then again as noted I always distribute compiled accDE applications to users (a RATHER LONG list of reasons exists for using accDE in place of an accDB). And for 20 years prior to the web, every access developer usually had to “cobble” together some kind of update system anyway.

    Since you not using any real features of web publishing (except that cool feature to auto-update the VBA front ends), then jumping to Access 2013 should not be a big deal, but you will loose the one feature you happen to be using!!

    And by dumping the use of the auto-update 2010 web feature, then you could most certainly have a mix of 2010 and 2013 desktops. In fact you can do this now by simply linking the 2013 version to the tables on SharePoint. As such, these front ends would NOT be web published, but would work the same as you have now.

    So you are at the end of the day using web published front ends with VBA code in them. This is legal, and a rather nice feature of 2010, but as noted, it not that hard to cook up a work around for this one issue.

    Last but not least:

    You can use Access 2013 to consume your EXISTING published application.

    And you can also use both 2010 and 2013 front ends also (but each 2013 user would need a FE copy and this would NOT be using the auto-update feature).

    So 2013 can consume the 2010 web based front end. In this case both 2010 + 2013 would have the auto update feature and you would be using the 2010 web system (which 2013 also supports).

    My spider senses says that moving to SQL Azure is not going to be a benefit unless you are experiencing performance limits of those SharePoint tables now.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Saturday, March 21, 2015 10:55 PM
  • You can see my other response. What they are doing is using the web publish feature on an Access 2010 VBA front end. This is legal, and if you don’t create any 2010 web forms, then the resulting web application is in theory still a web application, but without any web forms etc.

    Such web published front ends does result in one cool feature that “hydrates” down the VBA front end. So you change one form or report, then all existing users will “auto receive” this updated form or report or whatever that has been changed. It almost like source code control, since this ALSO allows multiple developers to work on the same application (as long as two users don’t modify the same form!). As noted, this really gives one a auto-FE update system.

    So you can web publish a regular VBA 2010 front end. When you do this, the application is converted into a “web” published database. You will even see the ribbon showing web tools etc. However since web 2010 allows a mix of VBA and web forms in the SAME application, then in theory it is still a web published application without any web forms – only VBA forms and reports will exist in the application.

    The noted benefit is that all front ends are thus auto updated at all times. A user can even “toss” their existing front end into the recycle bin – all they have to do it go back to the SharePoint site and they can re-download the front end. So the front ends are VBA, but they are “connected” to the SharePoint site and all changes to the application “syncs” with all users. And yes, this "feature" is much depreciated due to the new 2013 web system.


    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Saturday, March 21, 2015 11:18 PM

All replies

  • Your first two sentences pose a contradiction "we have a web app ... we use client front ends"
    So what is it, or is it both?
    It's also unusual but not impossible to connect an A2010 web app to Office 365 which came out years later and is associated with Office 2013. Are you sure about that, or are you connected to an older version of SP?

    Is this an intranet application? It seems that way because it seems all locations see the same SP tables. Is SP hosted by MSFT or in-house?


    -Tom. Microsoft Access MVP

    Saturday, March 21, 2015 4:02 AM
  • You can certainly gain performance and scalability by using Access 2013, since as you note it uses SQL server.

    However, be MUCH warned, as in many cases using SharePoint tables and how Access 2010 (or 2013) works with SharePoint tables can often run absolute circles around SQL server.

    Keep in mind that because you not “really” using any real feature of web publishing, then:

    You can jump to Access 2013 and CONTINUE to use the tables on SharePoint. So the “SharePoint” table feature DOES NOT require web publishing. It just “so” happens that Access 2010 web publishing sends the data up to SharePoint tables. However “up-sizing” the data to SharePoint is a feature of BOTH Access 2010 and 2013 support. In fact this feature been around since Access 2003! (but 2010/2013 is required for good performance).

    The other major difference is web publishing for Access 2013 ALWAYS sends the data to SQL server. As noted, some significant tweaking of applications may be required to obtain good performance over the internet – often MORE tweaking then the using SharePoint tables you have now. And the connection is MUCH more robust when using SharePoint tables.

    So you could migrate your data to Access 2013, and re-publish those tables. You would then link your front ends to SQL Azure, and not be using SharePoint tables.

    Last but not least:

    Access 2013 web publishing does NOT support the auto update and download feature you are using. However LONG before the web came along I adopted code to “update” the users front ends. So for some, this “auto update” feature is not a big deal. And I always preferred to distribute a compiled accDE so users cannot change things (so once again, the auto update feature of 2010 web is not a big deal for me).

    Since you “only” using Access web services and web publishing to to download the VBA front ends, then it quite easy to “get off” that feature and "dump" Access web services in this case.

    So Access 2013 does not have an auto update, but then again as noted I always distribute compiled accDE applications to users (a RATHER LONG list of reasons exists for using accDE in place of an accDB). And for 20 years prior to the web, every access developer usually had to “cobble” together some kind of update system anyway.

    Since you not using any real features of web publishing (except that cool feature to auto-update the VBA front ends), then jumping to Access 2013 should not be a big deal, but you will loose the one feature you happen to be using!!

    And by dumping the use of the auto-update 2010 web feature, then you could most certainly have a mix of 2010 and 2013 desktops. In fact you can do this now by simply linking the 2013 version to the tables on SharePoint. As such, these front ends would NOT be web published, but would work the same as you have now.

    So you are at the end of the day using web published front ends with VBA code in them. This is legal, and a rather nice feature of 2010, but as noted, it not that hard to cook up a work around for this one issue.

    Last but not least:

    You can use Access 2013 to consume your EXISTING published application.

    And you can also use both 2010 and 2013 front ends also (but each 2013 user would need a FE copy and this would NOT be using the auto-update feature).

    So 2013 can consume the 2010 web based front end. In this case both 2010 + 2013 would have the auto update feature and you would be using the 2010 web system (which 2013 also supports).

    My spider senses says that moving to SQL Azure is not going to be a benefit unless you are experiencing performance limits of those SharePoint tables now.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Saturday, March 21, 2015 10:55 PM
  • You can see my other response. What they are doing is using the web publish feature on an Access 2010 VBA front end. This is legal, and if you don’t create any 2010 web forms, then the resulting web application is in theory still a web application, but without any web forms etc.

    Such web published front ends does result in one cool feature that “hydrates” down the VBA front end. So you change one form or report, then all existing users will “auto receive” this updated form or report or whatever that has been changed. It almost like source code control, since this ALSO allows multiple developers to work on the same application (as long as two users don’t modify the same form!). As noted, this really gives one a auto-FE update system.

    So you can web publish a regular VBA 2010 front end. When you do this, the application is converted into a “web” published database. You will even see the ribbon showing web tools etc. However since web 2010 allows a mix of VBA and web forms in the SAME application, then in theory it is still a web published application without any web forms – only VBA forms and reports will exist in the application.

    The noted benefit is that all front ends are thus auto updated at all times. A user can even “toss” their existing front end into the recycle bin – all they have to do it go back to the SharePoint site and they can re-download the front end. So the front ends are VBA, but they are “connected” to the SharePoint site and all changes to the application “syncs” with all users. And yes, this "feature" is much depreciated due to the new 2013 web system.


    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Saturday, March 21, 2015 11:18 PM