Over on ScaryDBA.com I posted about the new Data-Tier Application (DAC) and DAC packages (DAC pac) this morning. You might be thinking, “Oh, now he’s on the Red Gate blog he’s going to rip it apart.” And you’d be wrong. I want to work from the premise that Microsoft is completely on to something. Not just with this cloud business, but with the DAC pac too. Here’s my premise, the DAC pac is a great way to deploy stuff to the cloud, but, using SQL Server Management Studio to create DAC pacs from existing databases you have no way to get that database into source control.

I’ve argued long and hard that DBAs and database developers absolutely have to start working more like application developers. We need to use as many of their processes as we can and we need to speak their language. Partly, this is self-serving. By getting into their space as much as possible and using their language, it’s much more likely that they can hear us when we talk. But mostly it’s acknowledgement that developers actually know quite a bit about developing and deploying software and we can learn from them. Yes, I can see you waving your arms. I haven’t forgotten about the DAC pac. Here’s the thing, you can’t easily get the DAC pac into source control from SSMS. or can you.

Red Gate SQL Source Control is a great way to take all the knowledge and comfort you have inside of SSMS and start to apply it building and deploying databases the way developers build and deploy their apps. What’s this have to do with the DAC pac you ask? Easy. You want to develop your database in SSMS so that you can then extract a DAC pac and apply that to a SQL Azure server, right (“Yes” is the correct answer here for the moment)? Well, use SQL Source Control as the mechanism for getting the database into SQL Source control. Develop it and get it ready for deployment to production and then just extract the DAC pac from the database, the one that’s in source control, has a branch or a label. The one that you can completely synchronize with your application. You know, that database. You’re done, it’s a win. Best of all, you don’t have to do anything special to SQL Source Control to set this all up. That database i deployed to SQL Azure from an extracted DAC pac, it’s already in my local copy of SVN. I’ve been using it for SQL Source Control testing and demo’s for a while. It went up on the web just fine after a nice clean deployment to my development server from source control using SQL Source Control’s mechanisms.

While I may or may not agree that the DAC pac is a great tool for deploying your database, there’s no reason why you can’t keep your development database in source control and start deploying it the way developers do, just with the DAC pac. But don’t be shocked if in some later blog posts I suggest some better ways than the DAC pac for managing your SQL Azure database.