I've recently started trying to deploy to one of my own databases in Azure using SqlPackage.exe. I've used it numerous times at work without problem, but on my own system at home, I keep running into the following error:
"Internal Error. The database platform service with type Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider is not valid. You must make sure the service is loaded, or you must provide the full type name of a valid database platform service."
As it turns out, you need at least SSMS CU#6 to get a version of SqlPackage.exe recent enough to deploy to Azure with SQL Azure v12. The copyright on the SqlPackage.exe executable must be 2015 (or later). Such a version comes with the latest versions of SQL Server Data Tools (SSDT). If you're unable to use the version of SqlPackage.exe that comes with SQL Server 2014 because it's too old ("C:\Program Files (x86)\Microsoft SQL Server\120\DAC\bin\SqlPackage.exe"), you can use the version that comes with SSDT for Visual Studio 2013 ("C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\120\sqlpackage.exe").
Showing posts with label sqlpackage. Show all posts
Showing posts with label sqlpackage. Show all posts
Monday, October 05, 2015
Wednesday, August 19, 2015
A really quick note about deploying SQL Server .dacpac files to SQL Azure
When you're using SqlPackage.exe to deploy a .dacpac to Azure, you must have access to the 'master' table in order for the tool to retrieve information necessary to create a diff of the database and deploy the differences during the Publish action.
For that reason, you need the 'sa' account, because simply having 'db_owner' on the Azure database is not sufficient.
For that reason, you need the 'sa' account, because simply having 'db_owner' on the Azure database is not sufficient.
Labels:
azure,
dacpac,
deploy,
deployment,
server,
sql,
sqlpackage
Tuesday, August 18, 2015
Debugging database deployments with MSDeploy and SqlPackage
I recently had problems deploying a database to Azure, and thanks to this article, I now know why. The best part of this experience is that I've learned to debug this in a much easier manner than relying on the unhelpful error message:
*** An error occurred during deployment plan generation. Deployment cannot continue.
Failed to import target model my-database-name. Detailed message Value cannot be null.
Parameter name: conn
Value cannot be null.
Parameter name: conn
The short of it is that:
1) you need to enable a log trace with these commands for dbDacFx and SSDT:
logman create trace -n DacFxDebug -p "Microsoft-SQLServerDataTools" 0x800 -o "%LOCALAPPDATA%\DacFxDebug.etl" -ets
logman create trace -n SSDTDebug -p "Microsoft-SQLServerDataToolsVS" 0x800 -o "%LOCALAPPDATA%\SSDTDebug.etl" -ets
2) Go execute the command that's causing you grief
3) Execute the following commands to stop the logging trace:
logman stop DacFxDebug -ets
logman stop SSDTDebug -ets
4) Open 'eventvwr' in the Run dialog available from the Start Menu
5) Go to the right side 'Actions' pane, and click on 'Open Saved Log'.
6) When prompted to convert the log, click 'No'.
The logs will display under the 'Saved Logs' folder in the left hand navigation tree, and you'll be able to inspect the errors that occurred. Good luck with deployment!
*** An error occurred during deployment plan generation. Deployment cannot continue.
Failed to import target model my-database-name. Detailed message Value cannot be null.
Parameter name: conn
Value cannot be null.
Parameter name: conn
The short of it is that:
1) you need to enable a log trace with these commands for dbDacFx and SSDT:
logman create trace -n DacFxDebug -p "Microsoft-SQLServerDataTools" 0x800 -o "%LOCALAPPDATA%\DacFxDebug.etl" -ets
logman create trace -n SSDTDebug -p "Microsoft-SQLServerDataToolsVS" 0x800 -o "%LOCALAPPDATA%\SSDTDebug.etl" -ets
2) Go execute the command that's causing you grief
3) Execute the following commands to stop the logging trace:
logman stop DacFxDebug -ets
logman stop SSDTDebug -ets
4) Open 'eventvwr' in the Run dialog available from the Start Menu
5) Go to the right side 'Actions' pane, and click on 'Open Saved Log'.
6) When prompted to convert the log, click 'No'.
The logs will display under the 'Saved Logs' folder in the left hand navigation tree, and you'll be able to inspect the errors that occurred. Good luck with deployment!
Subscribe to:
Posts (Atom)