Closed chriseaton closed 3 days ago
I have this exact problem at the moment. I'm wondering about an approach to this problem where you have an existing massive database you want to start converting to these projects. Is the only way to boil the ocean?
You could perhaps add a dummy view with the same result set shape (I assume you need it because other objects in your database project depend on it?) and then create the "real / ugly" view in a post deployment script?
You could perhaps add a dummy view with the same result set shape (I assume you need it because other objects in your database project depend on it?) and then create the "real / ugly" view in a post deployment script?
I did go down this path, unfortunately SQL compares don't run post-deployment scripts, only dacpac deployments do. That leaves me with the only ugly option - do a manual deploy. Not world-ending, but I just wish we could still get to SQL-compare without the "build" (skip validation) for certain scripts- like a forced script "add" into the dacpac post-build (which I do wonder if this actually could be pulled off, simply re-zipping the script into the dacpac... will maybe try tomorrow).
What would be the answer if you had database assets created by a non .net team but you need to reference those assets. I can't get a FK in place because of this. Adding it in the post script works the first time but then the next run it gets removed because it is not part of the table definition. Adding to the table definition results in an error so there is no moving forward.
There must be a way to either ignore or simply acknowledge an existing asset without having to define it yourself. When those assets are owned by another team, this does not work.
@chriseaton Can you share a simple repro, and I will have a look
@chriseaton Closing due to inactivity, feel free to re-open if you can provide a repro that relates to this project
We have a view that we'd like deployed, unfortunately it references an external database we don't have control of, which has a view that references other views, which reference other views all into a crazy ballooning set of references.
We'd simply like to deploy the view without having the build try to resolve it's references (have SQL compare scripts do that - in which case they will resolve on the server).
Is this achievable? Is there a way to include a view/script but not try to resolve it's external references?