UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> Awa's SQL Azure Databases Moved, Access 2013 Web App    
 
   
GroverParkGeorge
post Jun 4 2017, 08:35 AM
Post#1


UA Admin
Posts: 31,239
Joined: 20-June 02
From: Newcastle, WA


It appears that some -- if not all -- of the SQL Azure databases behind our Office 365 Access Web Apps are being moved from their original servers to different servers. I don't know yet how many, or which ones have been moved or will be moved.

This impacts you if you have a hybrid configuration in which you are linking an Accdb to the SQL Azure tables in your AWA. It also impacts you if you have linked other applications, such as Excel, PowerBI, PowerApps, etc. to those tables.

When the move is made, external connections are shut off to all of those applications except the AWAs themselves.

You can re-enable external connections. However, when you have done so, you'll then need to change the connections strings in any of your external apps (accdb, Excel, et al) to the new Server, database, UID and PWD. And, of course, redeploy those updated application files to any of your users who need them.

I have reported this problem to the Access team in Redmond. I'm hoping to get a response soon, but it is Sunday so not likely anyone will be checking email for a while. Moreover, I doubt they'll be able to do much about it because this is probably not under their control. They might not even have known ahead of time. I'll update this thread as I get feedback from MS.

In any event, if this has impacted you, please respond here. I'd like to make sure the message about the pain this causes gets back to those responsible.

--------------------
Go to the top of the page
 
ryan996
post Jun 5 2017, 04:07 AM
Post#2



Posts: 76
Joined: 16-June 13



Hi George,

Yes it has impacted me. I noticed that I wasn't able to connect through SSMS. I noticed that all the server/db and login credentials has changed. The other thing is that the load time of my app has slowed considerably in the last week. The load time of my app was 2-3 seconds before and it is now 13-15 seconds average, which is not a good experience for my users. I don't know if the administrators have also downgraded the type of server in Azure that our AWAs are running on. I do have integration with other apps / PowerBI, and CRUD operations through the SQL connection string, so this change will cause some pain.

The other thing that has changed is the inability to create new AWAs in O365. Though there is supposed to be a switch in the admin panel in SharePoint Online, I wasn't able to create new apps in the last week of May despite enabling the switch. A blog post stated that the ability to create new apps would be disabled in June 2017. I've spent some time studying MS Modern Lifecycle Policy, and the product should be supported for at least 12 months after the announcement, so they should not be able to disable the ability to create new AWA apps with 30 days notice. Many of us take snapshot copies of existing apps and need to deploy them for testing or development purposes, so we need to be able to deploy an existing AWA package.
Go to the top of the page
 
GroverParkGeorge
post Jun 5 2017, 08:34 AM
Post#3


UA Admin
Posts: 31,239
Joined: 20-June 02
From: Newcastle, WA


For me, fortunately, I've not noticed a serious degradation of performance, but I'm not surprised that a larger production application would.

I'm going to pass along the rest of your comments to my contacts on the Access team. I'm heart-broken by the cavalier way their loyal users are being treated here. I've used the word "unbelievable" a lot in the last two days. But the best we can do is try to salvage what we can and move on, IMO.

--------------------
Go to the top of the page
 
alancossey
post Jun 5 2017, 01:36 PM
Post#4



Posts: 545
Joined: 26-September 05
From: Norfolk, UK


Yes, this happened to me. A customer rang up this morning to tell me they could not get into their app. They use the standard Access front end. I checked the web UI and all was fine. After a bit of searching I noticed that read/write and read-only connections had been disabled. On re-enabling them the Access front end still didn't work. Then I noticed the password had been changed so I changed that in my connection string. Still it didn't work. Finally I noticed it was on a different server. When I changed that in the connection string, it all started working again.

Good job my customer wasn't doing anything important like trying to earn some money.

I do wish Microsoft would just say beforehand when they do these things. Surely it isn't that hard to do.

--------------------
Alan Cossey
Premier Data Technologies Limited
www.pdtl.co.UK
Go to the top of the page
 
GroverParkGeorge
post Jun 6 2017, 06:19 AM
Post#5


UA Admin
Posts: 31,239
Joined: 20-June 02
From: Newcastle, WA


I have heard back from the Access team. They are looking into what happened and will reply directly when they have a better picture of the events.

As I thought, the Access team themselves were not involved in the move; it doesn't mitigate the pain, of course, but it does suggest the people who made the change were not aware of the potential problems it would cause.

--------------------
Go to the top of the page
 
PhilS
post Jun 6 2017, 07:08 AM
Post#6



Posts: 404
Joined: 26-May 15
From: The middle of Germany


QUOTE
....but it does suggest the people who made the change were not aware of the potential problems it would cause.

Excuse me? - How can someone with at least the most basic knowledge about databases and connections not be aware of the problems it may cause for customers when the databases are moved to another sever and external connections disabled?

It think Microsoft has done it's Azure/Office365 brand a major disservice with this. Over here in Europe, particularly in Germany, businesses are rather reluctant to move any important applications and infrastructure to the cloud. One of the reasons for that is the fear of being at the mercy of an external entity, which could pull the plug from their applications any time. With the rather irresponsible behavior towards its customers, Microsoft proved that this fear is not completely unrealistic. - Both, the AWA deprecation and this database move have been handled poorly by Microsoft.

--------------------
Go to the top of the page
 
GroverParkGeorge
post Jun 6 2017, 09:26 AM
Post#7


UA Admin
Posts: 31,239
Joined: 20-June 02
From: Newcastle, WA


Okay, I'll go along with that position, it was something that should not have happened the way it happened. We could have expected this to happen at any time, under the terms of the SLA. We should have expected some minimal level of forewarning.

Keep in mind, though, that the basic configuration of the AWA is a web-based, or browser-based, front end and back end. Keep in mind that the use of a desktop accdb using ODBC links to that database is not part of that basic scenario. The move did not change the AWA's functionality in the browser, although there is some indication that performance is being degraded. It is more likely, in my mind, that without input from the Access team, the people managing those servers simply had no idea what they were doing here. I guess that's not saying much either, though, is it?

--------------------
Go to the top of the page
 
GroverParkGeorge
post Jun 7 2017, 07:45 AM
Post#8


UA Admin
Posts: 31,239
Joined: 20-June 02
From: Newcastle, WA


The Access team has responded to my request for clarification.

This was a result of a planned maintenance operation on SPO servers and tenants.

They will work with the owners of that operation to improve communication in the future.

--------------------
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    16th December 2017 - 09:24 PM