How can we help you today? How can we help you today?
Kendra_Little
Hi @Shaggy , Sorry for the delay on this one. For your second question, if there is a way to remove DeployChangesExecutionOrder, I am not knowledgeable about this one and am going to defer this one to other team members.  For your first question, the best way to deal with the merge conflict, here's what I recommend: A) In general it's good for DevA and DevB to regularly merge to their branches from trunk (or where-ever they are eventually going to merge TO), if their branches will be updated on a regular basis. This way they can be aware of other changes as they happen and not have to find out about them all at the end. [image] It's also best for both DevA and DevB to do that merge again right before they create the pull request. That way they can review the conflict locally and handle it.  C) If there's a race condition and someone merges in right before you, the Pull Request will notify you of the conflict as you mention. In this case I'd go back to the local repo, handle the conflict, and re-push. For handling the conflict locally, if you're using the SSMS plug-in, we recommend the free VSCode as a merge tool if you don't already have a favorite. To handle the conflict: In the trunk branch, pull changes Change to the branch in question (in this case BR1) Merge changes from trunk into BR1 -- in the example where trunk is named master: git merge master Open the sqlproj file with the conflict and merge the changes, in this case we would accept both (image below) Stage and commit Push [image] [image] Hope this helps, Kendra / comments
Hi @Shaggy ,Sorry for the delay on this one.For your second question, if there is a way to remove DeployChangesExecutionOrder, I am not knowledgeable about this one and am going to defer this one t...
0 votes
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