When I choose "Publish..." from a Visual Studio database project, it looks like, among other things, it runs the project's scripts on the database, but only the ones that have Build Action set to "Build". In other words, Build Action "None" scripts don't get run on the database as part of a Publish.
I have a database project but I do not have all the database's items in that project. Can I still keep scripts (for example, for stored procedures) in my project and run them on the database? How?
If I set them to "Build", I get build errors, because the items they depend on are not in the project. If I set them to "None", they don't run on the database at all. Is there a way to make them run on the database without needing their dependent items? If not, what is the best way to do this?
You could try setting the build action to none on the script, and then running the script from a post-deployment script.
There can only be one post-deployment script in each database project. You can add it by adding a new item and searching for post-deployment. Within the script, you use the command syntax to execute scripts.
http://www.mssqltips.com/sqlservertutorial/3006/working-with-pre-and-post-deployment-scripts/
It seems like there is no way to do what I am looking for; that Database projects were meant to have all the dependencies resolved.
Related
I want to use database project for script deployment in Azure SQL Server, I don't want to import full database. I just want to use database project for delta script. I added a project and included one script file with none as build action that contains create table statement , I am publishing the project, It's completing successfully but create statement is not executing. What is wrong here? Is there any other way to do this?
TLDR: Set your build action to "Post Deployment Script".
Longer:
What happens in SSDT is that all the files that have a build action of "Build" are built into a model of what the database should look like. When the deploy happens that model is compared to the target database and if there are any changes, a change script it generated and then optionally deployed.
If you have any file marked pre or post deployment script then they are either prepended or appended to the change script and will be run as part of the deployment.
If you have any files with a build action of "None" then SSDT ignores them, you could put anything in there, even an ascii picture of a donkey and the project will still build and deploy (obviously your ascii donkey won't get deployed anywhere).
If you just want to use SSDT to do your deployments you can just set the build action to pre or post deploy and it will be included. This is pretty odd though, either don't use SSDT or use SSDT and put the model of your entire database in there.
Personally, I would use SSDT properly and live the dream.
Ed
I have a VS2015 database project (sqlproj) and I created a lot of test data. I added a parameter to the PostDeploymentScript.sql file and when I need an empty database, I set it false and when I publish it doesn't include test data. When I need a demo database I set it true and when I publish, it also adds test data after deployment.
On the other hand, I want to create two different DACPAC files to prevent manual process and build both of them automatically at once. I searched a little bit and found several articles like this:
http://www.techrepublic.com/blog/data-center/auto-deploy-and-version-your-sql-server-database-with-ssdt/
but I couldn't apply what he said. What am I missing?
I created an (almost) empty database project (Lets say Base.sqlproj) which adds lookup table data after deployment. I created another DB project (Base_Plus_TestData.sqlproj) and added a database reference for the first database.
What I need is, if client needs to deploy empty database I'd like to give them the Base.DACPAC. If client needs to deploy a demo database with test data, I want to give them Base_Plus_TestData.DACPAC.
What should I do for this purpose and what am I doing wrong?
There a couple of extra options over what you already do with a switch to include data, I would choose the first :)
1 - Just give customers who want demo data a script to run after deploying the database (you could do something like use a powershell script/.net app to deploy your data and optionally the data)
2 - The post deploy script can be edited in a dacpac, you could build your project, copy the dacpac and then edit the post deploy script to include your data on one of the dacpacs.
3 - Create a separate ssdt project that references your main database project with a "same database" reference and the extra post deploy script - wheb you build you will get two dacpacs you can deploy either together if you want data or just the database.
If you also have data in your original dacpac to deploy you will need to copy it into the "with data" dacpac.
Ed
I'm trying to generate an output dacpac file which I can then deploy to different environments. Until now I was deploying directly from msbuild using the target publish, something like:
msbuild dbproject.sqlproj /t:Build;Publish /p:SqlPublishProfilePath=test.publish.xml /p:UpdateDatabase=True /p:PublishScriptFileName=test.sql
The size of the ouput script generated (just for reference as UpdateDatabase is set to true) is 2.5MB.
My new approach is to just build the project, store the dacpac and then deploy using sqlpackage with action 'Publish'. This new method is reporting some warnings which were not reported by msbuild SqlPublishTask.
For reference I ran the next command:
sqlpackage.exe /action:script /outputpath:test.sql /sourcefile:dbproject.dacpac /pr:test.publish.xml
and the size of the output script is now 4.9MB.
The specific warnings reported are not the concern here, the concern is that the script is different, my question is what is the difference?
and more importantly which one would be the best/safest method to do the deploy?
Sqlpackage.exe is more detailed and includes more objects during the deployment, it drops the permissions to tables to avoid any modification during the modification of the objects and then it proceeds to create or modify the them.
The difference is that ALL the objects are included in the script of sqlpackage, independently on whether they are different or not from the target database.
Although the warnings given were not a concern initially, using the sqlpackage method I discovered that some store procedure were not in the solution, only in the database. These 'orphan' sp were referencing tables being deployed, which is giving a warning stating that a change in the table may break the sp.
We've recently started using Database Projects in Visual Studio 2013. So far, it's great!
There are some things we'd like to be able to customise and I'm not sure if it's even possible.
We'd like to be able to have our post-deployment scripts appended to the SQL that is generated when doing a schema compare, so that when we create a deployment script, it comes with our post-deployment stuff all in the one .sql file. Is there a way to do that?
Also, we'd like to know if there's a way that the .sql file that is generated can be customised (much like a .tt file can be for entity framework).
Welcome to SSDT!
Pre/Post deploy scripts don't get used by the schema compare so if you generate a lot of scripts then set up PowerShell or a batch file to call sqlpackage.exe and set the action to script. I use this as part of a CI build to generate scripts for different environments and works great.
You can customize the output by choosing what to include or exclude in the output script but if there is something not supplied out of the box you can modify it by using deployment contributors which you can add or remove steps or do things like add your own transactions etc, for more details see:
http://blogs.msdn.com/b/ssdt/archive/2013/12/23/dacfx-public-model-tutorial.aspx
If you let us know more about how you want to change it, there may be something already available to help.
Ed
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)