As I mentioned earlier, we use Perforce as our source control package, so all of the scripts presented here are written for Perforce.  I’ll try to clearly explain, in terms of source control, the functional parts of the script, so that you can easily transfer this to your own source control package.  They should all offer the same basic features and some sort of command-line interface.  If you are a Perforce user, you may find it helpful to create a “non-expiring” login for this script to use.

Ok, sit up straight, eyes forward, let’s get started…

I assume that by now you’ve tried the script from Part 1, and have seen how easy it is to script out your database objects using Powershell.  The resulting scripts are the standard DDL scripts that you can generate from Management Studio, and for most of us, are just fine right out of the box.

What if, however, we need to customize those scripts?

One of the biggest headaches in most development groups that do any sort of SQL Server work is that of source control.  There are some commercial products that attempt to solve this headache, and from what I understand, some of them do a pretty decent job.  The only one that I have personal experience with is Microsoft’s Team Foundation doohickey, and I walked away from that unimpressed.

Being a “do-it-yourself” kind of guy, and looking for new and interesting ways to use Powershell, I’ve built a (pretty slick, if I say so myself) method of AUTOMATICALLY version-controlling my database objects.  No muss, no fuss, it just works, and nobody needs to remember to do anything.


On Saturday, September 13th, I’ll be presenting my 10 Ways To Abuse T-SQL session in Kansas City. If you haven’t seen this one before, here’s your chance! This is always a fun one, and always draws good feedback, even when I run out of time – which happens every single time…

Come join me – we’ll talk about SQL, sharks, make fun of developers, Justin Bieber, and this guy: