The Microsoft PowerBI Competition is now in full swing with the voting open to the public for the next week. (Check out my entry). As you can see below I just made my submission in time. I like to cut it fine! When I came to building my demo (check it out) I had a few different data sets in mind, but there were two main points that I wanted to highlight from my entry -

Previously I’ve written about the database unit testing framework tSQLt, you can read about it here, there is also an excellent Pluralsight course by Dave Green (blog | twitter) which you can find here. In this post I’m going to show you a method of version controlling your database and unit tests with SQL Server Database Projects in SQL Server Data Tools (SSDT). Setting up the Solution In my solution I’ve created two SQL Server Database Projects

Last week I was looking through the Recently Published Courses list on Pluralsight and noticed one on Database Unit Testing (check it out). Given that it was quiet at work as not everyone was back from holidays I thought it would be a good time to look into it. What is tSQLt? tSQLt (website) is a testing framework for SQL Server, that basically means it provides (almost) everything you need to write tests against your database.

SalesForce exposes a number of WebService APIs which can be used to access objects in an organization (see here for details). In this post I’m going to show how from a C# application you can use the Partner API. The Partner API is designed for those who want to develop applications which are agnostic to the objects in a given SalesForce account. This means that it will work for multiple organizations, which is in contrast to the Enterprise API which only works for a single organization and gives a strongly typed interface into that single organization.

This week I’ve been making some changes in one of my data warehouse projects, with the aim of making it a long lived and easy to maintain solution. One of the big changes that I made was the way I was staging the data from my different sources, and this meant re-working a whole bunch of SSIS packages. Specifically there were a bunch that pull data from SalesForce which needed to be cleaned up.

Chances are if you are using SQL Server in an enterprise environment you are probably using Active Directory groups to setup and maintain permissions, but how as a DBA do you know who the users are behind the groups and many there actually are? This is especially important for the sysadmin permission. In this article I’m going to show how to use PowerQuery to find all the users in Active Directory that have the sysadmin permission.