How can we help you today? How can we help you today?
way0utwest
This might help. https://voiceofthedba.com/2018/11/02/adding-sql-search-to-azure-data-studio/ / comments
This might help.https://voiceofthedba.com/2018/11/02/adding-sql-search-to-azure-data-studio/
0 votes
Ah, so in the release steps, there is no analysis of the code, just a review of which migration scripts need to be deployed. The scripts are already set and the parsing of changes is done in development to build those scripts. A pre-deployment to intermediate environments is what should be used to catch this type of issue. I'm looking for something that would help here, but I think this is problematic from our view in that we do perform some drops for procedures in some scripting. Anything that's pre-SQL2016 can't handle CREATE OR ALTER, and the standard pattern we have is: if exists() drop, create. I think that the solution I'd lean towards here is to fail builds that contain drops, not wait until the release stage. My initial thought is to capture a list of tables and store this in my db. This would essentially be a way of auditing the state of the db. If you maintained this in your existing prod (and qa/staging/UAT, etc), then you'd know what objects exist. After a build, I'd run a left join from this table to sys.objects, and if things were missing, I'd then fail the build or return an error to the user. This would help me detect drops. You could easily expand this type of check into views, procs, functions, users, etc. / comments
Ah, so in the release steps, there is no analysis of the code, just a review of which migration scripts need to be deployed. The scripts are already set and the parsing of changes is done in develo...
0 votes