How can we help you today? How can we help you today?
Kendra_Little
Hi there, Not sure if this bit is clear or not -- Azure SQL Managed Instances simply don't allow you to put the database into restricted user or single user mode. This is one of the limitations of Managed Instances. We don't have a way to work around that because Microsoft doesn't allow it to happen. Generally I would recommend that people work to be able to run deployments online without killing off all other transactions when possible. Is this an option in your case? If not, I would be curious to know what the specific pattern you have which prevents it -- there might be a more graceful way to work around the problem. If you do wish to kill off all active transactions, one workaround you may find suggested on the internet is to find another statement which supports ROLLBACK IMMEDIATE (Microsoft refers to this as the termination clause), which is supported on Managed Instances and to use that other commands and to turn that option on and then off. A list of commands that support the termination clause is here. However, this is definitely a hack and I would be wary of this approach. I personally have sometimes experienced a deadlock on some "ALTER DATABASE" commands which weren't pleasant to handle, and you can't put multiple ALTER DATABASE commands inside a transaction. So if you did hit a weird deadlock on the second command, you could end up putting the database into an odd state. I know this isn't a complete answer, but hoping to get more info on why you aren't able to do online deployments. Kendra / comments
Hi there,Not sure if this bit is clear or not -- Azure SQL Managed Instances simply don't allow you to put the database into restricted user or single user mode. This is one of the limitations of M...
0 votes
Hi Peter, I suspect that documentation page intended that "uncommitted changes" include changes in the database which hadn't been imported yet, but I can see how that wording is unclear. I'll follow up on that (I'm out all next week so it may be a little while before I complete it). I'll also chat with the team and propose that we move the "Create new branches" section at the bottom up to the top of the page and give a little more advice about how using feature branches makes it easier to work with Git. My preferred methodology with Git is to have each developer working in a feature branch: Import changes from your database to your feature branch as you are ready. Push your feature branch up to the central repo as often as you like as a way to back up your changes from your local machine -- - optionally building these branches whenever they are pushed if you like If your feature branch needs to live longer than a day, do at minimum a daily pull from master and merge into your branch When your changes are ready to go into a main line, use a pull request to merge in Effectively, most folks find it more straightforward to always merge changes into a branch when using Git, rather than to have shared branches where you have people pushing and pulling changes into the same active branch.  I find that the Azure DevOps Release Flow model often work for people when they are getting started as it is not overly complex, but some people still prefer the older Git Flow model which maintains a separate develop branch.  Hope this helps! Kendra / comments
Hi Peter,I suspect that documentation page intended that "uncommitted changes" include changes in the database which hadn't been imported yet, but I can see how that wording is unclear. I'll follow...
0 votes
Hello, To capture the schema for specific objects without data, you can use the SQL Compare command line.  Here's an example command. This example compares a database to the "schema-model" folder in the release artifact for a SQL Change Automation project. In an Azure DevOps pipeline, you can set up a step after creating a release artifact (but before deployment) and run this step, and it will write out a rollback script for the stored procedures, views, and functions which the release is modifying: <div>$SQLCompare="${env:ProgramFiles(x86)}\Red&nbsp;Gate\SQL&nbsp;Compare&nbsp;14\sqlcompare.exe"#&nbsp;full&nbsp;path</div><div>$MyServerInstance="InstanceName"</div><div>$MyDatabase="TargetDatabase"</div><div>$SchemaModelPath="C:\PathToReleaseArtifact\Project\Schema-Model\"&nbsp;</div><div>$OutputFile&nbsp;=&nbsp;"C:\PathToDesiredOutput\RollbackTest.sql"</div><br><div>$AllArgs&nbsp;=&nbsp;@("/server1:$MyServerInstance",&nbsp;"/database1:$MyDatabase",</div><div>"/scripts2:$SchemaModelPath",</div><div>"/Assertidentical",</div><div>"/include:StoredProcedure",</div><div>"/include:View",</div><div>"/exclude:View:__MigrationLogCurrent",</div><div>"/include:Function",</div><div>"/Options:AddDatabaseUseStatement,DecryptPost2KEncryptedObjects,DoNotOutputCommentHeader,IgnoretSQLt,IgnoreWhiteSpace,IgnoreWithElementOrder,UseCompatibilityLevel,IgnoreUsersPermissionsAndRoleMemberships",</div><div>"/ScriptFile:$OutputFile",</div><div>"/force"&nbsp;#&nbsp;This&nbsp;makes&nbsp;it&nbsp;overwrite&nbsp;the&nbsp;file&nbsp;if&nbsp;it&nbsp;is&nbsp;present,</div><div>"/LogLevel:Verbose"&nbsp;#&nbsp;%localappdata%\Red&nbsp;Gate\Logs</div><div>)</div><div>&$SQLCompare&nbsp;$AllArgs</div> Some notes: In an Azure DevOps pipeline, you will probably need to use the ReleaseName variable for the path to the release artifact If you are using a SQL Source Control project, you can do a similar pattern, but just point it to the folder holding your state in the release artifact If you want to script out ALL of these types of objects, not just those modified in a release, you can compare the database to an empty folder Coincidentally, I'm working on some improved documentation and examples for this right now [image] Hope this helps and let me know if you have questions, Kendra / comments
Hello,To capture the schema for specific objects without data, you can use the SQL Compare command line. Here's an example command. This example compares a database to the "schema-model" folder in ...
0 votes