Add manual dependency references to SSDT project? (aka, force deployment order of objects)

Viewed 31

tl;dr

Is it possible to add a manual "depends on" reference to items in an SSDT project? Or, during the build or publish steps.

I would also like to mention that the issue that is causing this need is not currently fixable. So "fixing the code" is not currently an option.


Longer version

I am working on an extremely large and complex database migration into SSDT projects. One of the issues I have run into and have yet to find a solution for is forcing deployment order of objects.

I have read many other StackOverflow questions, blog posts, reddit posts, etc. Unfortunately, nothing has led me to an answer.

Here is the problem...I have a view which touches 4 different tables. That view has 3 INSTEAD OF triggers on it to cover Insert, Update and Delete operations. The triggers split apart the DML operations into the correct tables and then perform the action.

This allows you to treat the view as an ordinary table without having to worry about this error: View is not updatable because the modification affects multiple base tables.

SSDT does not seem to realize that stored procedures who perform DUI operations on the view depend on the triggers. So when SSDT generates the deployment plan, it creates the view, then it creates the stored procedure, then it creates the triggers.

So because the triggers are created after the stored procedures...SQL Server throw error Msg 4405, Level 16, State 1, Procedure usp_Foo, Line 68 View or function 'dbo.vw_Bar' is not updatable because the modification affects multiple base tables..

However, if the triggers are created first, then it's fine.

So I need a way to force deployment order. SSDT controls this using "References" in the model.xml file. I can manually modify this file to add the dependency references myself. So each stored procedure that performs a DUI operation against the view, I add a references to the triggers on the view. I then recompute the file hash, update it in origin.xml, zip the files back up into a *.dacpac file and it resolves the issue.


So the question is...how do I automate this? I could build a script that unzips the file, scans the XML for views that have INSTEAD OF triggers, then scan for all elements with references to the view, and add references to the triggers. And this might work...but it's very hacky.

I have looked into Build Contributors and Deploy Contributors, but I'm still trying to understand what they do, their use cases and their abilities.

0 Answers
Related