Access Web Apps (AWA) is no longer be recommended and soon enough will not be supported by Microsoft. AWA will be retired from Office 365. If you're using SharePoint Online, you will not be able to create new Access Web Apps starting June 2017. The apps already out there will be shut down by April 2018.

The focus from Microsoft will be on Microsoft PowerApps as the tool to provide solution for both desktop and mobile devices.

--------------------

- Doug

When I said the program was fool proof, I hadn’t realized there were so many fools.

2. How long will InfoPath be supported?• The InfoPath 2013 client will be supported through April 2023.• InfoPath Forms Services for SharePoint Server 2013 will be supported until April 2023.• InfoPath Forms Services in Office 365 will be supported until further notice.

In our implementation we use FE clients ODBC connected to a BE database provided by an AWA. We never actually use the AWA functionality just the database it provides. So sounds like we'll have to move to a different DB at the backend - from the information currently available I'm not sure what this means in terms of timescales . Possibly the most obvious solution would be to move to Azure (which is what the database sits on anyway). However this has cost and expertise implications - we currently get the existing (limited) DB functionality free with 0365/Sharepoint. Anyone have thoughts on this aspect?

Generally speaking, costs to run a SQL Azure database at the approximate service tier that AWAs were using is pretty low (provided you don't have boatloads of concurrent users). And it's a per-service cost, not a per-user cost.

As far as expertise and ease of management, I'd say that the way you're doing it now is the long way around... if you can effectively use a SQL Azure backend provided by AWA, you can almost assuredly use a SQL Azure Database directly. In this case, I'd expect the "curve" to be very, very small.

Little consolation to anyone else that's decided to use AWAs, but you at least should get off pretty easy in the broad scheme of things.

Jack, the pricing on my existing SQL Azure databases suggests it's probably going to increase the monthly cost for a single database on SQL Azure for some people, and if you have deployed multiple databases within an Office 365 account, well, the math gets depressing.

For the $6.95 monthly price of one Office 365 site, I can deploy a dozen AWA spawned SQL Azure databases. For a basic, 5 DTU, 2 GB database, the monthly price for SQL Azure is $5.00, and for a Standard 10 DTU, 2 GB database, the monthly price is $15.00.

Given that most AWAs are probably okay with the basic configuration, the pricing on a single AWA is comparable. Given that the O365 account includes services more likely to appeal to Office workers than the ones included in Azure, I'd say it's a good deal. However, add a second AWA in your O365 site, and the advantage goes the other way. And with each additional AWA on your O365 site, the cost comparison gets more depressing from the budget POV.

One nice thing about the SQL Azure approach, of course, is that you can scale performance and storage up and down, which is not possible in the AWA environment. If your little AWA got to be popular and usage spiked from 2 users to 250 users, sorry. With Azure, you can respond appropriately.

Keeping in mind that inviting guests to use your AWA is NOT per user priced either; supporting 10 users is the same as supporting 500, price wise. Performance is another matter, as noted above.

All of that is now water under the bridge and we're left to pick up the pieces as best we can.

I'm not happy to see another "Access in the cloud" initiative being dropped.

I'm happy that Access itself is once again front and center in the development team's attention over in Redmond.

Feel free to comment at the site of the official announcement, particularly if you have invested time and effort in using AWAs and Microsoft stopping the creation of new AWAs in Office 365 in June 2017 and the removal of all AWAs in Office 365 in April 2018 is going to mess your business up.

We're a relatively small not for profit organisation, so costs are always an issue e.g. we use 0365/Sharepoint to share our data across sites avoiding the need for an in-house network. At the moment we have three AWA databases, these are effectively Development, PreLive/Pilot and Live for our main application. If we moved to Azure I think that we'd need a minimum of two PreLive/Pilot and Live - my assumption being that we could develop using some variant of SQL Server Express and then carry out final proving testing in PreLive/Pilot - does this seem a reasonable approach.

From my own perspective I have no experience of SQL server so I'm assuming that I need to get some level of expertise in this, plus I'd need to learn some level SQL Server Management Studio. Any advice on the best approach to developing the requisite knowledge also is there anything else that you think is needed.

Hi Mike - so we're not too sidetracked in this main news thread (and don't require approvals for posts), feel free to start a topic in the general forums and post a link back here so I can pick up on it. There's a fair bit of options but I don't really want to clutter up a news thread with an ongoing discussion on that (a link to a discussion would be nice for anyone wanting to follow the path as well though).

Announcement doesn't seem to mention Access Web Databases (2010). I assume these will be shut down too, but it would be nice to have confirmation of that and to know whether the timescales are the same.

I have a few applications running on AWD as AWA was never approved in our on-premises environment (plus the lack of table level permissions management in AWA was an issue for us). However, we have just migrated from on-premises to Office 365 / SharePoint Online so it looks like we'll be caught by this.

George, let me know if you have complications. It wasn't working properly from O365 to OnPremises at least in oct/nov2016. It only accepted SQL-2014 behind Access Web Services 2013 in SP. That is, when you wanted importing app files to work.Rob

George, here's the only combinaton that imports O365 exported apps files (for all we know). Everything else gave errors on the import.Rob

: Gerard Timmerman I continued this morning with replacing the SQL features on both the Application and Front-End farm-members with SQL2014 featurepack and SQL2014localdb + SQL2016 Management studio 16.5.1 and finally was able to import a 365 export!The SQL server is now the same SQL2014RTM version as in the 365 apps.

OK so I'm getting caught up in all of this and it is going to have a huge impact on what I'm doing.

I have several setups with Access front end. Some using the AWA as back ends. Only one is using the web app itself. I've also got some customers using Access 2010 web databases (hybrid - Access FE on windows machines and Web database on everything else)

What are the options based on the following objectives:1. to provide customers with an Access front end / Back end set up that several users can use simultaneously in different locations (using Windows laopto, desktop, notebook, tablets)2. To provide a solution for customer(s) on 'any device' which would include an Access front end on Windows for all the heavy lifting and an "any device" solution for day to day add/edit records

Can Power Apps be used to create something that will do this for customers who don't have Power Apps?

Is MySQl or SQL hosted on Linux hosting suitable for use as a backend?

My applications use Access (desktop) front ends connecting to AWD (Access Web Database - i.e. the 2010 version of the technology where tables are actually lists in SharePoint).

With at least one application, we will move the backend to SQL Azure. Cost goes from nothing (part of SharePoint) to about $300 per month (maybe less if we can schedule to not use 24/7).

The queries were all in the Access front end. Worked 'OK' due to the client-side caching mechanism between Access and SharePoint lists. All those queries need to be rewritten in T-SQL. As an example - one commonly used query (based on several other queries) takes about 15 seconds to run on Access FE with AWD backend once the data is cached. When data is moved to SQL Azure and queries left on the client, the query takes nearly five minutes. When the query is rewritten in T-SQL it takes less than a second.

For another system, we might just move it to a standard SharePoint subsite with tables as lists. We lose the Data Macros that were enforcing our business logic. Instead we will have to rely on business logic being implemented in the client which allows savvy users to circumvent it by directly modifying the SharePoint lists, but at least we can see who last changed records. We also lose the ability to easily deploy another copy of the database (subsite) but in this case that is unlikely to be a problem.

For an access-on-any-device scenario there is Citrix/Terminal Services and similar, though may bump up costs significantly if our internal corporate rates for Citrix are anything to go by (I think $30 per concurrent user capacity per month).

As others have noted, the loss of AWA, AWD is a real kick in the teeth as there is simply no viable alternative technology which can deliver the functionality at the same cost. I did play with PowerApps a while ago, but gave up on that almost immediately when the lack of functionality became evident.