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.
Publishing dacpac’s is a little bit of a pain when you have multiple databases, it can easily start to take minutes to hours to deploy changes depending on how many databases and the size of those databases. I wanted to understand more about the publish process and what we can do to speed it up as much as possible so I did some digging and this is a randomish post about how it all works and what we can do to make it faster.
I did a talk at the london .net meetup if you want to get an overview of what SSDT is and how to get started then I would recommend it: https://skillsmatter.com/skillscasts/9274-londondot-net-january-meetup This was aimed at .net developers rather than DBA’s so there isn’t much talk about “why you should use source control” etc as everyone in the room used source control already :)
I was talking to someone at a meetup recently who was really keen on doing continuous deployment for their database but they had a number of issues, the main was that because management wasn’t sold on the idea and the DBA’s had complete control to push back on all and every idea he had - there was no way he could deploy continuously. The accepted route for devops is management buy-in, if you do not have management buy-in then you can’t do devops.
There have been a couple of fixes in SQLCover this week, kindly submitted by John Mclusky (https://github.com/jmclusky): Code coverage not reported correctly for CTEs at the end of a stored procedure if the ‘with’ is immediately preceded with a semicolon and DeclareTableVariableStatement statements cannot be covered, so report falsely as missing coverage I have also changed where the releases can be downloaded from to use the github releases: https://github.com/GoEddie/SQLCover/releases The previous version is still available but I would recommend the latest version.
