If you read my other blog, Scary DBA, you may be aware that I’ve been doing a series of experiments with SQL Azure, learning about the costs, learning how to deploy databases to it, and most recently, learning that I can’t deploy databases that way. If you read this blog you know I’ve been trying to answer questions brought up on the other blog with Red Gate solutions. Yes, there is a method to my madness, this particular piece of the madness anyway.

Over on the other blog I has just found out that the DAC Pac incremental deployments are not currently supported in SQL Azure. With Microsoft pushing both Azure and the DAC Pac, I expect that to change. But, today, how do you get incremental changes out to your SQL Azure database? That one’s easy, Red Gate SQL Compare of course.

SQL Compare already works with SQL Azure. There’s nothing to it. The only trick, and it’s hardly a trick, is that you have to use a SQL Login to connect to the database. After that, it’s a snap.

Once I’m connected, there’s nothing to it. You can get move objects in either direction, as long as they are SQL Azure compliant. You’re just dealing with yet another source for SQL Compare at that point. It’s great. Here’s the output for the comparison I defined:

That’s it. Nothing to it. So, when it comes to deploying your code, you can put the power of SQL Compare to work. Not only can you run the compare as I just did, using the GUI, but you have a fully functional command line. It’s possible to get into automation of your deployments, which is a big deal for me. I’m a strong believer in automation. Because you can pull your structure from Source Control as well as another database, you can use your source control system to help manage the deployments. This is a huge win. Best of all, if you’re already using SQL Compare for your databases that you manage, you don’t have to learn much at all to move to SQL Azure. It just works. And best of all, it works in a a way that you are already completely familiar with.

This is still SQL Azure. You are running queries to pull back this information. This means that you will get charges for moving the data. It’s just something to keep in mind as you run the software.

Between this, SQL Azure Backup, and SQL Source Control, you can get a local copy of your SQL Azure database, get it under source control, and deploy changes to it as needed, using your source control system with it’s labels, branches, etc. as the basis for deployments. That’s the way to work.