SSDT: Tips, Tricks, and Gotchas

I wanted to add a short post to make sure I highlight some things that will trip people up or otherwise cause issues.

• When setting trigger order for triggers on a table, you could run into an issue with Publishing your database. The project will build successfully, but throw a “Parameter cannot be null” error for parameter “Key”. This is an internal bug with the product as of at least SQL 2012 CU2. It’s been entered as an internal bug within MS with a workaround. To workaround the issue, do not try to set the trigger order in the table definition, but rather put this code in a post-deploy script.
• This is supposed to be fixed in a future release of SSDT so your experience may vary.
• Importing encrypted objects may fail. If you want to store encrypted objects in your project, you’ll likely need the code in order to create them in the project.
• Unlike the Schema Compare option in VS 2010, there is no way to set the default Schema Compare options nor a way to filter out “skipped” objects in the schema compare.
• I’d love some ideas on how better to handle this. You may be able to save the compare within the project for future re-use, but I had little success with this in VS 2010 Projects so have been reluctant to try that route again.
• If your database uses FILESTREAM, you will not be able to debug using the default user instance that SSDT provides. You will need to point your debugging instance to a SQL Server install that supports FILESTREAM. See this forum post for more details.
• Set this in the Project Properties and point to an actual instance of SQL Server that supports the feature(s) you want to use.
• SQL Projects will substitute CONVERT for CAST in computed columns at the time of this writing. They also push default constraints with extra parentheses around the default value. If you clean these up from the target server, be aware that on your next Publish action, you could end up with extra work being done to make your target database use those parentheses or the CONVERT function.
• To work around this, do a SQL Schema compare after a release to find any areas where the schema on the server differs from that in the project. For instance you may see a DEFAULT (getdate()) in your server, but have DEFAULT getdate() in your project.  Add the parentheses to your project to avoid unnecessary changes.

Do you have any tips to share? Add them to the comments below.