SQL Source Control

Back around the turn of the millennium and during the final heights of the dot com boom, I found myself in London building the UX for the brand new online-only cahoot bank. (I then realised the miserable weather I was enduring was, in fact, summer and hastily returned to a balmy Aussie winter. But I digress.) As with most things dot com, days regularly stretched into nights and frequently consisted of copious amounts of both caffeine and beer. Mistakes were made. The team I was working in consisted of developers (clearly the intelligent ones), designers (the ones who made life hard for developers) and copywriters (the less said about these, the better). On one occasion, the latter decided that, in...

I must have struck a chord with the folks at Red Gate recently when I wrote about Automated database releases with TeamCity and Red Gate. Inadvertently, I managed to get this post out right in the final stages of their work on SQL Source Control 2 which added the ability to version static data. This was pretty opportune timing and caused me to rewrite – and significantly simplify – a fair swathe of the post. Clearly the post was a glowing endorsement of their tools, and rightly so. In conjunction with TeamCity, they’ve helped me to fill a fairly gaping hole in the CI process and bring the DB up to a first class citizen with the application...

Databases have long been the poor cousin of the application tier when it comes to many of the processes we take for granted in the .NET world. Source control management, for example, is near ubiquitous for application files and there are several excellent VCS products which make versioning a breeze. Continuous integration is another practice which although not as common, is still frequently present in a robust application lifecycle. Of course the problem is that database objects don’t exist as simple files that can be versioned, nor can you just pick them up and place them in a target location when you want to deploy them. You’ve got to consider the very nature of databases being...

I’ve previously written about Rocking your SQL Source Control world with Red Gate and was bullishly optimistic about the potential for finally providing the means for simple, effective version control of database objects. It turns out the post struck a chord with the folks at Red Gate and they asked me if I’d like to contribute to an article in Simple-Talk, a fantastic bi-monthly newsletter with about 150,000 subscribers. It’s now online here: Foolproof Atomic Versioning of Applications I’m a long time subscriber to Simple-Talk and it’s one of the few tech newsletter I actually still get delivered by email; everything else has been demoted to RSS or increasingly,...

I’m a big fan of Red Gate’s SQL Source Control, I really am. I raved about it earlier in the year and I still think it’s the best solution going for getting your databases under source control with Subversion. However, I’ve hit a glitch which unless I’m wrong, appears to be a bit of a design flaw; versioning changes in case. Let’s say I have a table, creatively named “MyTable”, and an equally creatively named column called “MyColumID”. It looks just like this: It’s all happily versioned under source control as indicated by the friendly green database: Now let’s say...

I knew it was going to be good before even seeing it. After all, SQL Source Control is from the guys who brought us SQL Compare and Data compare, two of my all-time favourite tools in the “stuff that would be a real pain to do without” category. They’re tools I tend to berate developers for not having and have regularly waxed lyrical about in the past, albeit it within 140 characters; until now. Versioning database objects very much fits into the same realm in that it’s a nightmare to do without a dedicated tool. The simplicity with which we version other applications files – HTML, images, classes, etc – hasn’t been...