When trying to apply a DACPAC to an Azure SQL Database I'm getting the following from sqlpackage.exe:
*** An error occurred during deployment plan generation. Deployment cannot continue.
The Element or Annotation class SqlDatabaseOptions does not contain the Property class CatalogCollation.
I've managed to use VS2017 with SSDT to create a package and then deploy it to another database using the SQL Server Object Explorer but it fails when I use sqlpackage.exe found in
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130
The Azure SQL Database Compatibility Level is set to 140 so I'm not sure if SSDT (v 15.6.0) is using a more modern version of sqlpacakage.exe, or where I would find it? I've also tried to run it from the Azure SQL Database Deployment VSTS task and get the same result.
I've tried mapping the command line switches found in this window but again, I still get the same error.
Is there a version of sqlpackage.exe that SSDT is using that I can't find, or is it a parameter that I'm missing?
For reference this is the command that I'm using:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130>sqlpackage.exe /SourceFile:"generated.dacpac" /Action:Publish /TargetServerName:"xxxxxxx.database.windows.net" /TargetDatabaseName:"xxxxxxx" /TargetUser:"xxxxxx" /TargetPassword:"xxxxxxx" /TargetTimeout:120
It seems you may need to update Microsoft SQL Server Data-Tier Application Framework on your computer. Please download the latest version here. After installation, you will find it on the following path C:\Program Files (x86)\Microsoft SQL Server\130\DAC\bin\SqlPackage.exe” and updates independently of SSDT / SSMS.
SSMS has its own version of SqlPackage. SSDT has its own version also, which you may find at C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\130.
Azure SQL is a PaaS Service which means it receives update transparently and relatively often with a new compatibility level.
Azure SQL is now 150.
When you create a new database it will be configured using the latest version.
However, your machine, your deployment agents might not have the latest tooling deployed.
When the tooling does not match the compatibility level of your database, the deployment will fail.
If you are deploying using VSTS Hosted Agent you are not in control, and it will always lag a little behind. In that case, the easiest fix is to reduce your database Compatibility level.
This is quite easy as you just need to run an SQL Statement on the database as follow:
ALTER DATABASE database_name
SET COMPATIBILITY_LEVEL = 130;
Related
I'm using Visual Studio 2017 and TFS 2015 to create an SSDT project and deploy the DACPAC via TFS.
If I test the project in Visual Studio by publishing a profile, I'm able to view all the changes to the destination database (ex. Dropping Tables, etc) in the "Messages" tab.
I'm not seeing that same kind of output when I publish the DACPAC through TFS. There are timestamps when Deployment has started and finished, but no information on what is actually modified in the database.
Is there anywhere I can view a log of database changes that occurred when a DACPAC was published?
EDIT:
I'm using a WinRM - SQL Server DB Deployment task in TFS Release Management to deploy the DACPAC.
You could add a command line task to use SqlPackage.exe tool to generate a difference report between database. The syntax is:
/Action:DeployReport /SourceFile:$dacpac-path /TargetConnectionString:$constr /OutputPath:$reportoutputfilepath
Useful links:
https://msdn.microsoft.com/en-us/hh550080(v=vs.103).aspx
https://www.francoisdelport.com/2016/06/continuous-deployment-of-databases-part-2-sqlpackage-exe/
There are several artifacts generated when you run deployment:
DeploymentReport_X.txt --> This one has the steps performed
your_project_name.publish.sql --> This is the actual script executed on source
My machine has the current (March 2014) version of SSDT, Visual Studio 2012 Professional, and SQL Server 2014 Developer. I have a SQL Server project (let's call it MyProject.sqlproj) that targets SQL Server 2014. I attempted the following:
MsBuild.exe MyProject.sqlproj
/t:SqlPublish /p:SqlPublishProfilePath=Somewhere.publish.xml
This fails with the following error:
Deploy error Deploy 72002: Internal Error.
The database platform service with type
Microsoft.Data.Tools.Schema.Sql.Sql120DatabaseSchemaProvider 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.
If I switch this project to target 2012 (and point to a 2012 instance), this same command runs successfully. I had previously asked a potentially related question, and the answer there resolved my problem then, but that's not the issue here -- I'm able to publish this 2014 DACPAC successfully if I use SqlPackage.exe directly.
What's happening, and how can I fix it?
The issue here is that the VisualStudioVersion environment variable isn't set, in which case the .sqlproj file currently defaults to targeting the VS2010 version (which does not support SQL Server 2014). Calling "set VisualStudioVersion=11.0" before running MSBuild will fix the issue.
Continuous Build Database Project fails when building on TFS server. We have Visual Studio 2013 Shell (Integrated) installed. There does not appear to be a way to install SQL Server Data Tools 2013 thru' Tools > Extensions and Updates... menu.
The redacted error is below...
C:\TFSBuild\XXX\XXX\Database_CI\Sources\Database\XXX\XXX.sqlproj (126): The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
Has anyone experienced this? Is there a solution or work-around? Is SSDT available for VS 2013 Shell for SQL Server 2014?
I have recently installed the Visual Studio Shell (Isolated) and (Integrated) on our build server and it does not include the SQL Server tooling components. I found out that SQL Server tooling is built in to the following versions of Visual Studio (see here):
Express for Web,
Express for Windows Desktop,
Professional,
Premium, and
Ultimate
I would recommend installing at least the Professional version and then you should get the SQL Server Data Tools components that are required for building.
SQL Server Tooling is now built into the above listed versions of Visual Studio 2013 (SSDT and Visual Studio versions) and the latest March update of Visual Studio 2013 now includes SQL Server 2014 support (SQL Server Data Tools for SQL Server 2014 is available.)
To force your build to use the correct version of MSBuild set the Process - Advanced - MSBuild arguments = "/p:VisualStudioVersion=12.0" (without the quotes) as shown.
You can download SSDT for VS2012 here and that should get the database pre-reqs on your build server.
I do see mention of "Sql Server Tooling in Visual Studio 2013" on this landing page, and I think it implies these tools should be available with the shell, so if you could, check to see if you have that targets file somewhere on your build server.
Go into C:\Program Files(x86)\ and do a "dir Microsoft.Data.Tools.Schema.SqlTasks.targets /s /b" and see if something comes up.
Right now it's hard-coded to this location:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets
You might want to see if the file already exists, but in another location, like in an "v12.0" folder instead of the "v11.0" subfolder.
EDIT
Actually, what's the value on line 126 of your .sqlproj?
If it says this:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v11.0\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Change it to read:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\SSDT\Microsoft.Data.Tools.Schema.SqlTasks.targets" />
Then have everyone test it using diagnostic logging, then gather the logs and compare them to make sure that version is consistent so you can start phasing out the legacy bits.
I had the same issue and fixed it by downloading and installing the following
dacframework.msi
SQLDOM.MSI
SQLLS.MSI
SQLSysClrTypes.msi
from here:
https://www.microsoft.com/en-au/download/details.aspx?id=42295
I have created an application in Visual Studio that uses a .mdf database and executes SQL scripts on it. The program imports and exports reports to and from Excel. I want to be able to give this program to team members, but they get an error "error: 52 - Unable to locate a local database runtime installation. verify that SQL Server Express is properly installed and that the Local Database Runtime feature is enabled."
I assume they get this error because they do not have SQL Server installed. Is there anyway I can include the minimum SQL Server components needed within my deployment? What is the minimum requirement? Thank you!
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity