If you already have a source code repository for your app code or other databases or you have another team that uses source control then just use theirs. If you don’t then use whatever the members of your team have used most, they all basically do the same thing and having your database under source control is a million times better than not having it under source control. There is an exception, if you use visual source safe and I know people do still use it then use something else, it hasn’t had a release in over 10 years and in my opinion is no longer fit for purpose, especially when you consider the other free options available to you.

I had a lot of fun yesterday presenting my talk on how to go from not having your database in version control to deploying to a CI database, running unit tests and generating deployment scripts for a QA/Prod database so effectively how to build a fully functioning continuous delivery process for SQL Server databases in less than an hour (my wittering was about 40 minutes and the demo just over 10).

Niche tool of the day If you know what a deployment contributor is and have wanted to see what steps were in a plan and have got bored setting a breakpoint in visual studio and using the watch window or something to display the steps in a plan, you might find this useful. It is really simple, all it does it look through all the steps in a deployment plan and dumps (Console.

To help with this scenario (it is pretty specific): You have a table that has columns that you do not know about when you create the dacpac, possibly you have a customer who modifies your schema after you deploy. If you deploy your dacpac those columns will be dropped which is bad and you don’t want to completely ignore all changes to a table what do you do? You can now use the new version of my deployment contributor with a filter like SqlPackageFilter=KeepTableColumns(Employees)

In my deployment filter I have been asked a couple of times to allow columns that exist on a table that do not exist in a dacpac to be ignored so that they are deleted. The typical scenario is that a vendor supplies a database and then customers can add extra columns (I know what a horrible place to be but it happens). I had a look at this and my first thought was that if we use the deployment filter and add an IgnoreType(SqlColumn) that it would work but it obviously doesn’t.

I am going to ignore the fact that people don’t want to install visual studio on a build server, in the future there will likely be a way to install just the required components rather than everything. Today, the way I see it is that I develop in Visual Studio, I am happy to install Visual Studio on the build server for me Visual Studio is as dependency for SSDT.

I installed the 2016 SSMS client recently and in one way or another any of my apps that I have written that use the DacFx ScriptDom have all broken in slightly different ways. One app throws a type conversion error and another just failed to find any statements in a batch. When I started debugging the problem I noticed that I got this when I started one of the apps from Visual Studion:

I wrote a test earlier and forgot one of the two cardinal rules about tSQLt so I was running my test suite and the test did not run, I re-deployed and it still didn’t run so I thought I would create this handy list of things to check that mean that even when the tests exist in the database they do not run: Are the tests in a schema that has the tSQLt test class extended property?

The slides are up: https://github.com/GoEddie/SQL-Server-Containers Any questions shout!

Really excited by my first post on medium, haven’t really used it before but found it to be a really nice tool: https://medium.com/@edelliott.the.agilesql.club/let-s-start-doing-profes…