What is the SSDT Dev Pack It is basically a collection of tools that I find make developing in for SQL Server in SSDT better or easier. I will never have the time on my own to do as much for t-sql that resharper does for t-sql but this is a start and maybe someone will invest in tools for t-sql developers at some point :) The general idea is that if I want to do something and can make it re-usable then I will add it here.

DevOps isn’t running SQL Server in a container and pushing code to it from Jenkins When we talk about DevOps we envision that we have the ability to check-in code, spin up a new environment, deploy, test and push that code to production and be in the pub at 4. We know that by having the right tooling in place we can make releases more reliable and more frequent enabling us to deploy the changes that the business want when they want them rather than every x days/weeks/months/years/decades.

Every now and then I come across this error in SSDT, normally when trying to publish and the odd thing is that the description never matches the actual cause (if you desperate for the cause it is because you can’t connect). The thing I like about the description is the way it tries to tell you what is wrong and what server you are connecting to but it fails at both and instead tells you about an unrelated error and a database name instead of a server name.

I have upgraded the ssdt dev pack to support visual studio 2017 and fixed a couple of minor annoyances and have started to think about how to improve it going forward. The first feature of sorts is the ability to clear the connection used by the quick deployer without having to restart visual studio. Secondly I am pretty convinced that the main thing people use it for is the quick deploy, the tSQLt test builder and I use the keyword formatters so I have moved everything else to underneath a menu item saying “deprecated” - if anyone really wants one of those features then let me know and I will keep it but I will likely remove them at some point.

I have been quite interested by vs code and have been using it more and more recently. I use it for all my GO (#golang FTW) work and also powershell and I have been toying with the sql tools team’s sql extension which is great. For a long time I have thought about bringing the SSDT experience to other IDE’s like Jetbrains IntelliJ but because I have been using vscode quite a lot recently and separately I have been doing more and more javascript and typescript I thought it would be interesting to see how hard it would be to write a vscode extension that lets me build dacpac’s.

This one is for the DacFx nuts out there, it can’t be a very big club but judging from the occasional emails I get about it, the quality is very high ha ha. If you have a TSqlModel and you want to make a change to it, you have a couple of choices: - Create a new model and copy over everything - Use AddOrUpdateScript AddOrUpdate can only update scripts that you add (i.

A teams maturity shows in its choice of tools. I have seen quite a few different development teams in wildly different environments and the single fact that really stands out is that you can tell how good a team is by the tools that they use. It isn’t always the specific choice of which tools they use, although that can be important, it is the fact that they evaluate and chose to either use or ignore new tools.

What is this? Well if you read the name aloud “SQL Server Continuous Deployment in a box” then, if I have done my work correctly choosing the title for the blog, give a hint :) what is the big idea? There is really some great tooling for SQL Server - second to none really when it comes to RDBMS’s and setting up Continuous Deployment pipelines is actually pretty simple once you know which parts to plug together.

If you have ever tried to debug a program that used the TSql Script Dom to parse some T-SQL you will know that the process is extremely slow and this is due to the volume of NoViableAltExceptions (and others) that are thrown and then caught. Because these are first chance exceptions they are being handled and it is the way that the script dom interacts with Antlr and the Lexer that they use.

Following on from yesterdays blog I was wondering about the comparison of objects that were the same and how the IgnoreWhitespace, IgnoreComments, IgnoreKeywordCasing and IgnoreSemiColonsBetweenStatements flags affected the comparison. To be fair I was only interested in IgnoreWhitespace but actually it turns out that those four are very closely related. When the deploy happens, where a script in the source and target are compared the process is: 1. Loads of things we will skip 2.