I mentioned a couple of posts ago that we were having trouble backing up a database from SQL on Azure to a local machine.

One of the problems was that we didn’t have access to the Azure portal, so we asked the CSP with access to do the backup and send us the BACPAC file. We assume that backing up to Azure storage would permit the backup, and get around the issue we were having with timeout.

As it turns out, even this doesn’t work. The backup still times out. Microsoft (and the other CSP) are still working on it.

Misery loves company! At least I’m glad someone else had the trouble.

Next time you think about creating a database with 50,000+ tables on SQL Azure, think again.

Wave 2 of the 2019 Release of Dynamics Business Central is out. There are a host of new features; check here for more information as we dig in. There are a few changes in this release that impact current on-premise users, and one of them has a deadline in 2020, so we thought we would discuss them first.

Here are the changes:

• First, the Windows Client is no longer available as of this release. The March 2019 release is the last release with the Windows client.  More detail is below.
• Second, the C/Side development environment is no longer available. All modifications must be converted to extensions.

If you have followed (as we have) Navision to Dynamics NAV and now to Dynamics 365 Business Central, you’ve seen changes to the user interface. The “Classic” interface that ended with the 2013 release to the “Role Tailored Client” that 2009 and following supported, there were changes. In the midst of this, Microsoft released the Web interface. Until the 2018 release of Business Central online, the Role Tailored Client (Windows client) and the Web client looked as much the same as possible.

Business Central changed the look of the product. The home screen from the Online Version of Business Central (as of today) is shown below.

For me, it is a change, but for production users, it will take some getting used to. The old interface (2015 version) is below for comparison.

If you haven’t read my previous post on this subject, you might want to. Otherwise, you’ll be starting this hopefully-not-an-epic-saga in medias res, as they say.

After a bit of digging, I discovered the probable cause of my trouble: the way SQL Azure works. Here’s the link from Stackoverflow that finally turned the light bulb on for me.

The key phrase is this one:

When an Azure SQL Server gets overloaded or goes down, it will disconnect a number of connections and when you reconnect you will get sent to another SQL Server.

Yep. That’s it. And the nasty things about that are (a) you don’t know when it might happen, and (b) since it’s internal load-balancing and redundancy behavior, you have no control.

It’s great for apps running on Azure, because it evens out response time and avoids down time.

But in the case of backing up SQL Azure locally, it throws a monkey-wrench into things. This can also beat you up if you’re writing code against Azure, but that’s the subject of another saga.