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
Related
SQL Server on a SSIS server has been upgraded to SQL 2017 from 2016
SSIS Packages are built in projects that Jenkins runs as a BIML Build (BIML Studio 2018) on a Build Server
Visual Studio Standalone has been upgraded as has the project deployment file
When we change the jenkins job to look for 2017 it thinks its looking for 2012. The environment variable in jenkins reflect what we see in the Windows PATH environment variable
When its run as 2016 the BIML Build runs fine, but the connections, script tasks, merge commands have script errors - see image link.
Error Screenshot
The scripts are built in C# and used to build each component for SSIS.
We need to know what the likely cause of the errors in SSIS are.
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;
We have a sqlproj that targets SQL 2014 locally. The build and publish work as expected from Visual Studio.
Now we are trying to build and deploy the database project to Azure Database v12 using VS Online. We are getting errors stating the SSDT targets the wrong database. This makes sense as Azure Database and SQL 2014 surpport different features and produce different warnings/errors. Every article/post we have found online shows how to change the target platform from the GUI at design time.
Our assumption is the platform can be targeted at build time, same as changing the target platform of a class library. However we are not able to locate a list of available arguments for a sqlproj targetplatform.
Does anyone have a link or know the key=value property to set for the VS Online build parameters?
Thank you
The value is stored in DSP property of project, so you can specify /p:DSP=Microsoft.Data.Tools.Schema.Sql.SqlAzureV12DatabaseSchemaProvider MSBuild argument in Visual Studio Build task.
As long as everything in your project can be deployed then:
/p:AllowIncompatiblePlatform=true
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
Best practices or tools for installing a SQL Server database
I have a SQL Server database designed with the SQL Server GUI database editor/Visual Studio.
What is the best way to "install" that database on other systems. Said another way how should I ship this thing?
I know I can save the scripts and set the primary/foreign keys with T-SQL but I suspect their is something better. I guess you could have people restore from backup but that does not seem very professional.
What other choices are there and what are the pluses and minuses?
For it to look professional make a small setup program.
You currently have sql scripts that you use to create your db.
Make yourself a small xml file that contains the path to your scripts.
Create a small c# library that will connect to the db server, and run those scripts.
You can test this outside of the setup, in visual studio, then add it to the setup like this.
To do this from your setup all you have to do is put the xml file in a component so it is deployed,
And create a custom action in your setup, that will call your C# lib, read the xml and run the scripts on the sql server to create your db.
Also, from a setup program it's easy to set a registry key to identify the version of the your db that you just installed.
The minuses and pluses: It's a bit of work to start with, but with this you'll have all the ground work done to handle upgrades automatically later on, to do so, just add an upgradeScript section to your xml, an attribute called version for each upgrade script, and simply compare it against the version of the db you have save in the registry. The advantage is this way it can easily scale with your project.
My previous answer is mostly to keep full control on the deployment and upgrades.
I have searched for more built-in and streamlined solution that goes along with the DB designer mode you have used.
I found that in the version Studio 2005 Team Edition for Database Professionals of visual studio there might be deployment features.
Build and Deployment
You've seen that you can generate a
T-SQL update script manually via the
Schema Comparison tool. However, as
part of the build process, DB Pro
edition can generate a complete script
for deploying your database project.
This deployment script can do either a
complete build or an incremental
update. The build process can even
consolidate all of your pre- and
post-deployment scripts into one
complete deployment script. You can
deploy the script via the Build |
Deploy Selection command right from
within Visual Studio 2005. Under
project properties, you will find a
number of options to control and
adjust the build process. The Build
tab contains the core settings, such
as Target connection, Target database
name, and Block incremental deployment
if data loss might occur. You'll note
there is also a Build Events tab that
you can use to type pre- or post-build
event commands. DB Pro edition uses
MSBuild for its build process and
supports integration with Team Build
if you're using Team Foundation
Server.