It is a constant source of frustration for some people that it is hard to download SSDT or SSDT-BI or you download the wrong thing. This is an example of some frustration: https://social.msdn.microsoft.com/Forums/sqlserver/en-US/c82354d0-2f88-4… Anyway, this is now sorted as there is a single page to download SSMS or SSDT: https://msdn.microsoft.com/en-us/library/mt238365.aspx?f=255&MSPPError=-… and SSDT and SSDT-BI: https://msdn.microsoft.com/en-us/library/mt204009.aspx Feel free to grab Preview or RTM versions!

It isn’t a Pre compare script When you use SSDT to deploy your dacpac, a pre deployment script lets you run some T-SQL scripts before the script which brings your database up to date with your dacpac. The important thing to note is that the process is: sqlpackage compares the dacpac to the database sqlpackage generates a list of changes to make sqlpackage generates the T-SQL statements to make those changes sql package either creates a script for later execution or deploys the changes The script that is created *or* is executed contains, 0 or 1 pre deployment scripts, the statements to generate the required changes and then 0 or 1 post deployment scripts.

This is part of a series on how to take the Adventureworks database and bring it in line with modern standards. How do we put a legacy SQL Server database into source control? What issues do we face and how hard is it? Then how do we build a continuous integration pipeline and possibly move towards continuous deployment. This series takes a look at how we achieve this whilst also implementing some coding standards and making an imperfect database a little bit better.

This is part of a series on how to take the Adventureworks database and bring it inline with modern standards. How do we put a legacy SQL Server database into source control? What issues do we face and how hard is it? Then how do we build a continuous integration pipeline and possibly move towards continuous deployment. This series takes a look at how we achieve this whilst also implementing some coding standards and making an imperfect database a little bit better.

What am I doing? Creating a publically available version of the adventureworks 2012 oltp database but by putting it under source control, implementing unit tests and improving the design and code to fit modern development guidelines. Why? There are two aims, firstly to show how to take an existing database and safely get it into source control. Once it is under source control we can start to document how it works and write unit tests which will allow us to make changes to it knowing that we are not breaking backwards compatibility or losing any functionality.

I see the same question again and again “I am using SSDT but it takes a long time to publish changes, how do I make it faster?” or the ever useful “SSDT is too slow”. Anyone who has used SSDT knows that doing a publish can take time, how much time typically varies depending on a number of factors: Is the database local or on the other side of the earth (high latency / possibly low bandwidth)?

I have put the code for MergeUi on github now: https://github.com/GoEddie/MergeUi That is all.

What is MergeUi? A Visual Studio Addin to create and edit MERGE statements in SSDT projects. What have you done? I have released a new version of MergeUi, thanks to Luca Zavarella for prodding me into getting this release out and for pointing out some bugs! This has a number of bug fixes and a new UI, the old one was pretty ugly, although this still isn’t 100% perfect but it should be more usable.

Hopefully this should put the ORM debate to bed, either use an ORM or don’t but please don’t access tables directly… There are obviously reasons behind all of this but if you follow this golden rule you will have a happy DBA and user base. Comments: Anonymous May 21, 2015 - 17:28 well - no one wants a sad well - no one wants a sad panda. Ed Elliott May 21, 2015 - 20:15

When you deploy your Sql Server code, there are two approaches, there is the manual way and the automated “compare & deploy” way. Manual The manual way is where you track what changes you have made and when you want to release, build a script or set of scripts which contain the updates. If you are modifying objects then you should use alter or drop/create and you need to manually create rollback scripts (should you need them).