What are DACPACs and how do I use them?

I had someone ask me about DACPACs recently.

DACPAC technology had fallen off of my radar after I had seen demos of the feature at a SQL Saturday many years ago.

In short, a DACPAC is a file that contains definitions for the objects of a database. This file can be used to create new databases or update old databases to a new version. For the most part, existing data in the updated database should be preserved. DACPAC technology is intended to replace the bundles of .SQL scripts and the giant "Hail, Mary" scripts that are often used to update databases.

At the time of that SQL Saturday demo, which was probably in the SQL Server 2008 timeframe, DACPAC technology was new and there were a lot of gotchas. IIRC, it was presented as a way to create databases in SQ:L Azure.

A few weeks ago, I noticed that SSDT was creating DACPAC files. I've long been a user of the database comparison tool provided by SSDT and other "Data Dude" descendants, but I didn't give the "freebie" DACPAC file that SSDT generated for me a second thought.

Since someone asked, I thought that I would spend some time researching this and write it up for the blog.

Things in the DACPAC universe seem to have improved substantially, and I found the following links useful:

• Jamiet does a braindump of his DACPAC knowledge on his blog.
• Pieter Vanhove relates his DACPAC experience and goes through various methods of applying DACPACs.
• Technet has a page on DACPAC.
• Bob Beauchemin provides some examples of using DACPAC functionality with Powershell. 
• The wiki over at StackOverflow has some quick points. 

According to the wiki, the DACPAC scheme still makes a copy of the target database and subsequently deletes the old one. That might be a showstopper for many large databases and was the main reason that I banished DACPAC to the back of my brain. However, I don't see many complaints on the web about this and that made me suspicious. In some very limited testing of a single-table database with four columns, I did not see any creation of mysterious databases. Perhaps the situation has changed with SQL Server 2012 and the wiki is out of date?

(While performing my limited tests, I noticed that a certain amount of downgrade-ability might be feasible. By simply applying the 1.0.0.0 DACPAC to my 1.0.0.1 database, I could remove a column. I'm not sure how I can exploit this, or if it would work on a non-trivial database, but this is the sort of think I like to keep in the back of my head as a possible future trick.)

In short, DACPAC seems to have matured into a viable deployment strategy. I intend to look for situations where I can use this technology to improve the speed and quality of deploying new database versions.

SugarSync Is No Longer Quite So Sweet

Over the last few years, I've spent more time following business issues in the IT industry than I had when I was younger. Perhaps it's just another mark of getting older.

Over the holidays, a news item caught my eye: SugarSync has stopped giving away free storage.

It's the hallmark of any new technology or developing area of business:

• Someone comes up with something new. 
• Many other players pile into the new space.
• Some time passes
• Players that can't make money (or generate the growth numbers they want) leave the new field and the space consolidates.
• The consolidation can go down to just a few companies. Those companies do not always include the one that created the space.

We have seen this with cars (in the first part of the 20th century, there were hundreds of small manufacturers in the US alone. now there are only two behemoths that are headquartered here and a few dozen firms based overseas). Other technologies (radio, television, ISPs, RDBMs, hard drives, and personal computers to name a few) and business areas (department stores, malls, convenience stores, hardware stores) have gone through the same evolution.

In the case of consumer-oriented, internet-based, replicated storage, I believe that DropBox was first and SugarSync followed. (I'm ignoring things like rcp, unison and such. Even though they have been available for decades in some cases, they never caught on past the sysadmin or power *nix user crowd.) With SugarSync changing it's business model, I can't help but wonder if we are seeing more evidence in "the internet" turning away from the free-for-all model (so to speak) to the same old charge-'em-at-the-door model that we've seen for generations. Periods of consolidation can presage increased profitability for the survivors.

A few years ago, I was an avid SugarSync user. I used their Windows and Android clients. I chose SugarSync over DropBox, Box, Skydrive and Mesh because SugarSync had an Android client and a the most liberal policy with respect to free space. IOW, they gave away more GB than their competitors.

At some point, the Android client stopped syncing my photos properly. At that time, both Google Drive and Microsoft Skydrive became viable alternatives. I need Google and Microsoft for other reasons, so SugarSync was the odd man out. I retired my SugarSync clients.

With industry heavyweights giving away storage space, SugarSync has a hard row to hoe. Microsoft and Google can afford to give away space, as a sort of loss leader. In the long run, I think that the online editing provided by Microsoft and Google will become increasing attractive to users. DropBox has name recognition and is widely supported by popular apps. Box has the enterprise orientation that DropBox doesn't (at least not yet). I could see a larger company buying up DropBox or Box. I am not sure where SugarSync fits into the market, five years down the road.

I would say that the best path for any of these small firms would be an acquisition by a larger player that already provides some sort of SaaS and supports multiple platforms. This leaves Apple and Microsoft out, but a consumer-focused organisation like Yahoo might do nicely. Amazon might find it easy to integrate SugarSync into their S3 storage offering and it might be worth something to them if the costs are right.