So I figured out how to disable the triggers from being part of a DACPAC, but unfortunately that's just a user level setting in Visual Studio, so I can't save it to source control and deploy the solution with those changes.
There's got to be some way to filter out the triggers from the DACPAC in the definition of the deployment pipeline task. But I have no idea where to start; all I see are some text fields and none of them are even generic "command line options" fields...
I have a database project in Visual Studio, and I need to exclude the database triggers from the generated DACPAC, because one of them is LockdownTriggers which prevents triggers from being altered - and that's causing issues with the other triggers; as soon as LockdownTriggers is deployed, it's automatically enabled. and then the rest of the deployment fails trying to alter other triggers that are now locked. Is there any way to prevent the database triggers from being deployed as part of the DACPAC? Or at least exclude LockdownTriggers, or prevent it from being enabled until the deployment is over?
I found it! Searched around online some more and it looks like I need "Advanced Deployment Settings" (accessible via Project Properties > Debug > Advanced).
Let's say that someone - for some reason - manually creates a SP in the database (and does not add it to the database project). If we now run the publish wizard of the database project, will the manually added SP be dropped or not?
Short answer: No, it won't be dropped.
If you publish from the database project (as in, right click and publish), then by default it is off: An Overview of Database Project Settings (I know this is from 2010, but the defaults haven't changed)
The project setting is called: "DROP Objects in target but not in project", and found on the "Debug" tab. When you right-click, publish you should get the standard publish profile dialog that gives you the "Advanced" button with below described options.
In the publish profile, it is called "Drop objects in target but not in source." It is unchecked by default, and can be changed from going to the "Drop" tab of "Advanced Publish Settings".
Here you get additional options to not drop specific object types.
I would recommend checking this value, rather than relying on the defaults (which can be verified by creating a new publish profile).
As always, when dealing with production databases, I'd recommend checking the script before allowing it to run. These machines, man, you can't trust them.
Suppose you have a database project and you do NOT have "Always re-create database" checked off in your Database.sqldeployment settings. And suppose you deploy to a server that already has a database by the name of the one you are deploying.
Under what other circumstances will the database deploy generate a script with a "DROP DATABASE" statement?
If you don't ever, ever, ever want your database to be dropped by the deployment script generated by right clicking your database project and selecting "Deploy", what are some of the steps you can take to prevent this?
In addition to the "Always re-create database" NOT being checked off, you should also check the Development tab on your database project's Properties page. Make sure you define a target connection. When you don't define one the project will always and only deploy as-if the target database does not exist. This behavior is by design. see this link for more details.
My suggestion is to create the connection using Windows Authentication so each user would have access to the extend they are supposed to.
Also please note that you will have to do this for each Deployment Configuration (e.g. Debug, Release, etc.)
I personally set the deploy action to just create a script and run it manually to be on the safe side!
I have a Visual Studio 2010 Database project, from which I want to generate a script
that simply puts up this database to another machine. The problem is that i can't find a
solution for this.
As I started the project, I imported the shema from a database on my development pc.
The Schema Objects were generated and all tables and scripts where under 'Schema Objects -> Schemas -> dbo'. Over the time, some things changed, some where added. And by using right-click -> deploy,
the changes were made to my local database successfully.
But now I want to deploy to another machine. The problem is, that in the release folder of the project, there is only a xml dbschema file containing all tables and scripts that i can't import
with sql management studio (or i just can't find out how) and the a deployment script which is nothing more than some checks followed by the pre- and post- deployment script, but without any tables or scripts in it.
So please, how do i export the database from Visual Studio, so i can easily put it up on another machine?
Marks--
You likely have already resolved this, but I thought I should answer your questions for the benefit of others.
Yes, you can deploy from Visual Studio to different machines. You can also do it from the command line, using VSDBCMD. And you can create a WIX project to give a wizard for others to install it with.
If you can connect to the target database from your dev PC, you can deploy to it. To do this:
Select another Configuration from the Solution Configuration drop down. Normally, the Project will come with "Debug" and "Release" baked in. You can add another configuration to allow you to deploy to various targets by clicking "Configuration Manager."
Right-click your Project and select 'Properties', or simply double-click Properties under the project.
Click the Deploy tab. Notice that the Configuration: drop-down shows the same selected configuration as "active."
Change the Deploy Action to "Create a deployment script (.sql) and deploy to the database."
Next to Target Connection String, click "Edit" and use the dialog to create your deployment connection to the target database.
Fill in the Target database name, if different.
For each Deployment Configuration (e.g., Debug, Release, etc.), you will probably want a separate Deployment configuration file. If you click "New," you can create one for the current configuration. The new file will open, and you can check and uncheck important things about the deployment.
Note: If you check Always re-create the database, the script will DROP and CREATE your database. You will lose all your data on the target! Be careful what you select here. Most people leave that unchecked for a Production target. I check it for Development or Local because I want a fresh copy there.
Save your changes to the file and to Properties.
To deploy to the target, be sure to select the correct Configuration. Click Build/Deploy [My Database Name]. You probably should experiment with this so you are familiar with how it works before trying it on a live environment.
Good practices: build a similar environment to production ("Staging") and deploy there first, to test the deployment, and always back up the database before deploying, in case something goes wrong.
For more info, please see:
Working with Database Projects
Walkthrough: Put an Existing Database Schema Under Version Control
Visual Studio 2010 SQL Server Database Projects
Is it's possible to point your Visual Studio to your new target database? 1. Properties of your Database project, Deploy tab, set the fields in Target Database Settings.
Now when you generate a deploy script, the resulting SQL file will be the various CREATe / ALTER / DROP etc that will align the target database with your schema.
You could always create an empty database and then do a schema compare in Visual Studio between your database project and the new empty database. You can amend the generated schema update script to also create the database (since the script will be to update an existing empty database)