22 June 2018
22 June 2018

SQL Code Analysis from a PowerShell Deployment Script

Guest post

This is a guest post from Phil Factor. Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 30 years of experience with database-intensive applications.

Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.

He is a regular contributor to Simple Talk and SQLServerCentral.

Database code analysis becomes more important as the team doing the database development gets bigger and more diverse in skills. Hard-working database developers sometimes check-in ‘temporary’ development code, by mistake, so it is always good to have a way of flagging up SQL Code issues and ‘smells’ that are agreed to be incompatible with ‘production’ standards.

Database Developers like to agree and share a common set of styles and conventions, so that they can work easily on all parts of the database code. Where the developers need to work across applications, rather than just on the database, these pre-release checks on the source become even more important, because these checks should indicate where code review might be helpful. SQL Code Guard can work with either a database, or the source code.

We all have different views of what constitutes best-practice, so SQL Code Guard allows the team full control over what gets checked, and what is ignored. The most important aspect of checking on code is to ensure consistency. The team need to be able to share settings easily and change them when necessary. Code analysis settings are best kept in source control with the version.

Automating static code analysis on a database

SQL Code Guard’s static code analysis rules are now built-in to SQL Prompt so that developers can usually avoid checking in suspect code. The command-line version of SQL Code Guard can read the code analysis settings from SQL Prompt, and can be used simply in PowerShell. This means that SQL Change Automation, and any other PowerShell-based process, can be adapted to run automated SQL code analysis.

Delivery teams can create and share a configuration file, defining which rules to include or exclude, for development and build tests, so that the report that is generated reflects, consistently, the current development standards.

The current command-line version of SQL Code Guard can be downloaded from the Redgate site as a ZIP file, and should be installed in a directory, with all the files together. As long as the command-line version is fully-referenced by its path, it should work fine.

Listing 1 shows a simple way of using SQL Code Guard in PowerShell to check a live database. You will, of course, need to fill in the correct values of the parameters. Be careful, also, to ensure that your Windows user has rights to create a file at the outfile destination.

Listing 1

The output of the program has interesting information such as the number of code-smells being searched, but the only word we are looking for in this example is ”Error”. There is also a log file that can be stored with the documentation of the build.

I’ll show in a moment how to view the resulting XML file, containing the code analysis findings.

Automating static code analysis on source code

You can check the code in any SQL file in any database build script (.sql file), or directory with .sql files in it. Here is a typical format of source control directory, but any directory structure is OK, as it will be searched recursively for any .sql file.

The PowerShell code is even simpler, as there are fewer parameters.

Listing 2

Using a code analysis configuration file from SQL Prompt

If you are using the code analysis feature of SQL Prompt, you can use it to save the code analysis rules settings into a configuration file.

Within SSMS, select Manage Code Analysis rules from the SQL Prompt menu, configure which rules you want enabled or disabled, and then save your settings by clicking Save as…, changing the file location to a shared folder and clicking Save. You can also save the configuration file from the Code Guard add-in for Visual Studio. The UI saves it in %APPDATA%\SqlCodeGuard.Addin\settingsv3.xml.

Listing 3 shows the PowerShell to view the configuration file to get a list of what is being checked and what isn’t.

Listing 3

You use your XML configuration file with either a database or source code.

Listing 4

Viewing the XML file

So far so good, but the result is an XML file. There are plenty of ways of viewing it once you can get it into a table. Listing 5 shows one way to do that.

Listing 5

Which will give something like this:

As this is scripted, there are plenty of ways of making the reporting side as elaborate as you wish, even sending email reports, the destination of which is based on the name of the object. You can even use PowerShell to attach the relevant report to the SQL script file as a block comment if you have a consistent file-naming convention that is based on the name of the object.

The simplest possibility is to convert the XML file to HTML for a website or email-based report. This can be done relatively simply in PowerShell by using the .NET XSL Translator. The XSLT file is created on the fly, so it can be parameterized to give additional information such as the server being tested or the date.

Listing 6

This will give an HTML-based report like this:


Currently, the command-line version of SQL Code Guard is free to use, subject to the license conditions. It provides a good way of checking the code of any SQL Server database development as part of a continuous delivery. It integrates with other Redgate products. It can, for example, use the code analysis checks, as determined by the development team using SQL Prompt. It is easy to use as part of a DevOps toolchain. More than anything, though, I like it because it is a great way of saving me from embarrassment!

Guest post

This is a guest post from Phil Factor. Phil Factor (real name withheld to protect the guilty), aka Database Mole, has 30 years of experience with database-intensive applications.

Despite having once been shouted at by a furious Bill Gates at an exhibition in the early 1980s, he has remained resolutely anonymous throughout his career.

He is a regular contributor to Simple Talk and SQLServerCentral.

Share this post.

Share on FacebookShare on Google+Share on LinkedInTweet about this on Twitter

You may also like

  • Article

    Sometimes the tool just fits - using SQL Change Automation and Octopus Deploy for Data Change Control

    From a business risk perspective, data change can be just as significant as code or schema change. Sometimes even more so; an incorrect static (or reference, or master) data change can drive your software’s behaviour more dangerously askew than pretty much any bug can. Imagine treating a retail customer for an investment fund as a corporate by

  • Article

    Unearthing Bad Deployments with SQL Monitor and Redgate's Database DevOps Tools

    Sudden performance issues in SQL Server can have many causes, ranging all the way from malfunctioning hardware, through to simple misconfiguration, or perhaps just end users doing things they shouldn’t. But one particularly common culprit is when deployments go wrong: I don’t know a single DBA who hasn’t been burned by a bad release. To

  • Article

    We don't need no documentation - automating schema docs in SQL Change Automation

    “Understanding the existing product consumes roughly 30 percent of the total maintenance time.” Facts and Fallacies of Software Engineering by Robert L. Glass. You should be documenting your database schema. I know it, you know it. Having current, accurate documentation available accelerates time-to-resolution for faults, aids tech-to-business conversations, and is a regulatory requirement for a great number of firms.

  • Article

    How to import an existing database to SQL Change Automation

    The Visual Studio extension of SQL Change Automation (SCA) allows you to adopt a migrations-first approach to database source control and deployment. There are a number of different ways teams can get started with SCA, in Visual Studio, and chere I’m going to show to get up and running when there is already an existing development database.

  • Article

    Deploying Multiple Databases from Source Control using SQL Change Automation

    Quite often, in a database development project, you need to create several copies of the database under development. They need to be to the current version of the build, or a previous specific version. You need to fill them with a version of the development data that is anonymized. For regression or integration testing, you

  • University

    Take the SQL Change Automation (with SQL Source Control projects) course

    In the SQL Source Control course, you can learn how to capture database changes, add them to a source control repository and make manual deployments.

    This course will take you a step further and show you how to use SQL Change Automation alongside SQL Source Control to introduce automation into your pipeline.