I exported a bacpac from Azure SQL Database and am trying to import it on my local environment.
It works perfectly on my development machine running SQLServer 2016, but if I try and install it on a server running SQLServer 2012, I get a compatibility issue.
'A project which specifies Microsoft Azure SQL Database V12 as the target platform may experience compatibility issues with SQL Server 2014'
It is definitely not any of my stored procs/tables etc as it is not using anything specific to newer SQL databases.
I am using the latest SSMS and have also tried installing some of the Data Tier application hot fixes that some people have mentioned, but no joy.
Related
I have an SQL Azure database and connect to it in SQL Server Management Studio. I do Export Data Tier Application and then Import Data Tier Application for the .bacpac file to get it into my localdb. Or I use Tasks - Deploy Database.
Either way, it worked up until recently and now I get an error
Online index operations can only be performed in Enterprise edition of SQL Server
I am using SQL Server Management Studio versions below (from Help - About). Any ideas?
SQL Server Management Studio 15.0.18369.0
SQL Server Management Objects (SMO) 16.100.46041.41
Microsoft Analysis Services Client Tools 15.0.19342.0
Microsoft Data Access Components (MDAC) 10.0.19041.1
Microsoft MSXML 3.0 6.0
Microsoft .NET Framework 4.0.30319.42000
Operating System 10.0.19041
Among bug fixes in SSMS 18.9:
Fixed in issue where importing a bacpac into SQL Express may fail. See SQL Server user feedback.
This issue with SSMS 18.8 had been acknowledge by the product team, but was fixed:
I apologize for the inconvenience of this issue, we are working to include a fix in the next release of SSMS. In the meantime, installing SSMS 18.7.1 (https://learn.microsoft.com/sql/ssms/release-notes-ssms?view=sql-server-ver15#1871) will allow you to complete the bacpac import operations on SQL Server Express.
If instead of using localdb you can upgrade to or use SQL Server 2019 Developer Edition, then you won't have any issues. Developer Edition is free and has the same features as Enterprise Edition. You can download Developer Edition from here and then update it with the latest cumulative update from here, after that try to import the bacpac to the Developer Edition instance.
I just ran into this same exact problem again today. I exported our database from Azure into a BACPAC and was having trouble with SSMS loading it into SQL Express.
Just by pure luck, I found SSMS 18.9 was released today and appears to have fixed the issue in my case.
I am trying to deploy a local database to an azure sql databse.
When i use the tool in Management Studio (Tasks > Deploy Database to Microsoft Azure SQL Database) I get an error when the process starts to export the database. I get the same error when I try to export the bacpac manually. The error is:
Could not extract package from specified database. (Microsoft.SqlServer.Dac)
Internal Error: Ese could not be initialized. (Microsoft.Data.Tools.Schema.Sql)
Internal Error: Ese could not be initialized. (Microsoft.Data.Tools.Schema.Sql)
Out of Memory (Microsoft.Data.Tools.Schema.Sql)
A few hours of google searching is coming up with nothing.
I came across a tool called sqlpackage.exe that I am going to try, but I would really like to get this working from the tooling in Management Studio.
Management studio version: 13.0.15700.28
Local SQL Server Express version: 13.0.4224.16
Do these versions matter? Before I go and re-install everything, I assume they are independent of each other?
It is best to use the latest GA version of SSMS, especially when targeting Azure SQL Database. Newer SSMS versions can be installed side-by-side with older versions. However, that is generally needed only when you need to support old SQL Server versions like SQL Server 2005. The latest GA SSMS version (as of this writing) supports the SQL Server 2008 through SQL Server 2017. The current preview version also supports SQL Server 2019.
I've created an new SQL V12 database on azure. I've been enabled to update that database once to the model we have in our database project. We did this by using the 'Register as Data-tier Application' in SQL Management Studio.
Now we have an update on our model and we want to update our database again with a new DACPAC. When we use the function 'Upgrade Data-tier Application' (again trough SQL Management Studio) we get the error message:
TITLE: Microsoft SQL Server Management Studio
Databases registered as a DAC database must be hosted by an instance
of SQL 2005 SP4, SQL 2008 SP2, SQL 2008 R2, SQL 2012, SQL 2014 or
Microsoft Azure SQL Database. (Microsoft.SqlServer.Dac)
------------------------------ ADDITIONAL INFORMATION:
Unable to proceed with DAC operations on the target instance because
it does not support DACs. Specify another instance, or upgrade to a
version that supports DACs. (Microsoft.Data.Tools.Schema.Sql)
Very strange notification cause the database is already registered as Data-tier application and has been deployed once. I can't find any logs giving more details.
Our Database project has the target platform: "Microsoft Azure SQL Database V12" so that is the correct one.
Did you get anywhere with this? I'm encountering the same error. Need Azure SQL V12 so I can include Always Encrypted CMK/CEK and column encryption settings with the dacpac. Also, I'm deploying to a
I tried deploying from SSMS 17.2 and VS2015 w/ SSDT 14.0.61021.0 with no success.
I had originally published to the same DB with the DACPAC target as "Azure SQL Database" (not V12). Then later needed to change to V12 so I could build the dacpac with CEKs, CMKs and column encryption settings. After changing to V12 I started getting the same failure message.
I was able to publish for V12 target from VS2015 SSDT to the existing DB if I unchecked the "Register as Data-tier application" checkbox.
Also, I created a new DB and made my first dacpac deployment the one targeting V12 and it succeeded as well. I would think the dac framework would be able to handle the target Azure SQL DB to Azure SQL DB V12, but it seems not.
Hope this helps you or someone else that runs into this.
We've recently upgraded our development server from 2014 to 2016. We had already been using some 2016/Azure V12 functionalities on production in certain views.
Now that we want to restore a recently exported bacpac file from our production database on Azure, it fails with the following message:
Perhaps the internal DB engine is still running on 2014? I couldn't find anything concrete about it on Google.
The documentation on STRING_AGG() indicates the feature is available in Azure SQL Database and SQL Server 2017, but not SQL Server 2016. You need to use only common features if you want to import BACPACs between different versions.
If this was working before the on-prem upgrade, I suspect that was before the proc with STRING_AGG() was created or changed.
I took a project where I have to do a few fixes to a website and I'm having several problems trying to import the DB from a backup to my local computer.
The message I got is the following:
ADDITIONAL INFORMATION:
System.Data.SqlClient.SqlError: The database was backed up on a server
running version 12.00.2000. That version is incompatible with this
server, which is running version 11.00.3000. Either restore the
database on a server that supports the backup, or use a backup that is
compatible with this server. (Microsoft.SqlServer.SmoExtended)
The thing is I'm running SQL Server 2014 Management Studio and it is a 12.2000.8 version so it should work, but it doesn't.
As a second option I tried to generate the script (as I can connect to the remote DB) but it also doesn't let me. It just gives an error somewhere in the middle of the creation of the script.
Any ideas what could I be missing or what can I do to fix this?
I'm working with win 8.1, VS 2014 & SQL Server 2014 Management Studio everything up to date.
Regardless of the version of management studio you're using, the version of the database instance sounds like it's 2012. If you create a backup with 2014, you won't be able to restore on a 2012 instance.