March 11, 2022 at 8:00 pm
I work in a db development shop where it is common practice to disable the building of SQL code in SSDT projects. In other words, I have a stored procedure called sp1.sql, and I set the BuildAction to None. Object is never seen by the IDE, never gets compiled, and its only put into a DACPAC if the developer manually includes that script into the deployment script.
This is nuts, right?
They can't use schema compare. DACPACs are empty except for the manual scripts they create. Target databases must be in a known state before deploying a project since it can't use the delta magic of the DACPAC. So much SSDT capability is lost.
As a consultant, I feel obligated to guide the team towards best practices, but as an outsider I don't want to rock the boat.
Has anyone ever seen this done before? Are there profound benefits of leveraging (deleveraging?) Visual Studio and SSDT in this way? I think they could use pkzip and it would be even simpler and about the same capability.
Any thoughts or opinions are greatly appreciated.
March 12, 2022 at 8:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
March 14, 2022 at 11:25 am
The biggest benefit I can think of is that this method provides total control over how changes get deployed, rather than relying on SSDT's schema-differencing and updating tech, which is not always ideal. Perhaps they've been bitten by this in the past and no longer trust it.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.
March 16, 2022 at 2:18 pm
Yeah, but you can set the project to "build" but not to "deploy" in the solution's configuration in Visual Studio. That's what I generally do,. I want to "build" the project so that I get the benefit of Visual Studio/SSDT telling me where I screwed up (e.g. errors/warnings), but set the project to not "deploy". Works great when it's my own databases, not so great when we have to work with a vendor database where we've integrated our code.
Maybe it's for source code control (i.e. that's all they are using it for)? Maybe it's for more explicit deployment control like Phil said (especially if it's code integrated with a vendor/third-party database)? Maybe they just don't know how to use Visual Studio/SSDT effectively? Who knows?
I don't think it's "rocking the boat" to ask your peers in your shop "why", seems to me that would be better than asking us. You might get an answer that makes sense (or not, in which case maybe you have a teaching opportunity). 🙂
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply