In an earlier post I mentioned some of the limitations of SSDT. It’s worth covering them in a little more detail as they are significant.
The most significant issues relate deployment. Deployment for SSDT involves setting up a publish profile with a destination database to upgrade. This gives you the option of either publishing directly to the database or generating a script to run for the deployment.
Maximalist approach (with no control)
This means storing in version control production:
- Logins & passwords
- app role passwords
- master keys for encryption
- SSDT does not handle multiple file groups. Because clearly nobody would actually use that in production
Single file generated for upgrades
While SSDT provides the option to upgrade the database in place, but this a somewhat risky option for a production database. It is generally preferred to at least have the option to inspect what will be deployed.
Unfortunately for SSDT the upgrade generates a single file. In practice this means is that if the database upgrade fails for any reason recovery is rather complex. You’ll need to work out where the upgrade script failed and then what action you will take from there.
6 thoughts on “SSDT Limitations”
Can I use SSDT with Visual Studio Express 2012 for Windows Phone? Do you know alternatives to use local databases within this edition?
I'm not sure whether you can use SSDT for Windows Phone. It seems to be more focussed on SQL Server, which I'm reallt not sure would be a good idea (or available) on Windows Phone.
That aside, I really wouldn't be recommending using SSDT.
When you deploy you can use a deployment contributor to filter the steps, so you can stop it dropping users that don't exist in the dacpac or anything you like really (filegroups etc).
You have to write your dpeloyment contributor in .net or I have a generic one:
With more details:
SSDT is great and the extensible api makes it really good for multiple environments, even if you do have to do smoe up front work to get it going.
I responded over here: http://sqlblog.com/blogs/jamie_thomson/archive/2015/02/20/response-to-ssdt-limitations.aspx
nice to see this, it looks like it would resolve the issues I'd experienced.
It's a pity this isn't available out of the box and that you need to write code to enable this. I'd expect this to be a configuration option, ideally say a config file you could pass to this.
I appreciate the comments, I'll reply to your blog post.