Settings and activity
11 results found
-
40 votes
Scott Paist
supported this idea
·
-
78 votesScott Paist
supported this idea
·
-
212 votesScott Paist
supported this idea
·
-
344 votesScott Paist
supported this idea
·
-
76 votes
Thanks for all the feedback on this suggestion. The team will take the item under review and we’ll update here with next steps.
Scott Paist
supported this idea
·
-
207 votesScott Paist
supported this idea
·
-
77 votesScott Paist
supported this idea
·
-
79 votes
Kendra
responded
An update for users on the status of this suggestion:
An ‘object locking’ feature was added to SQL Source Control following the creation of this item which can helps users working in a shared database environment not write over each other’s changes.
This may help prevent accidental commits in some cases, as there is a “Locking” tab which allows users to see which other users are working on specific items.
Locked items are still eligible to be committed, however, and there are cases where users will want to commit an item — perhaps to a specific branch in source control which is not ready to deploy — even if the item in the database is locked.
We have found at Redgate that the easiest way to enable alignment with distributed source control systems such as Git is to empower users to use dedicated development databases rather than shared databases. Tools…
Scott Paist
supported this idea
·
An error occurred while saving the comment -
131 votes
An error occurred while saving the comment Scott Paist
commented
Of course, a built-in merge tool is preferable. I shouldn't have to go out of SQL Source Control to merge.
An error occurred while saving the comment Scott Paist
commented
It would be fantastic to be able to use the Visual Studio merge tool for this.
Scott Paist
supported this idea
·
-
476 votes
Thank you everyone for the suggestions and votes for this over the years.
I’d like to surface up a workaround for the “linking” problem which is mentioned in the comments. For the use case of easing pains around environment setup with a large number of databases, we have had customers find success using code based off Alessandro Alpi’s blog post: https://alessandroalpi.blog/2016/06/28/automatically-link-databases-to-red-gate-sql-source-control/
I do understand that this is a broader issue and hear that many of you also want command line or API support for the product in general.
If there are specific scenarios or workflows that would be useful to automate for you, this feedback is also very useful, and if you have details on the type of VCS you use and the workflow (such as a branching model) that it would fit in to, that would be very helpful for us to hear as well.
Scott Paist
supported this idea
·
-
480 votes
Thank you everyone for your comments and votes on this over the years. While I don’t have a 100% full resolution for this suggestion, I can sum up our current recommendations here. Continued feedback is very welcome.
Our current recommendation is to use the post-deployment script feature of SQL Source Control (released in V6.3) to manage SQL Server Agent jobs.
An example script for this is here: https://documentation.red-gate.com/soc/common-tasks/working-with-pre-post-deployment-scripts/create-sql-server-agent-job
As some commenters in this thread have alluded to, it is possible (and sometimes very common) for SQL Agent jobs to have steps that touch multiple databases on a single SQL Server Instance. For this reason, some customers prefer to create a separate database for instance-level management and objects (sometimes named DBA or similar) and choose to manage things like linked servers and SQL Agent jobs with the post-script associated with that database.
This separate-database architecture also makes sense if the jobs…
Scott Paist
supported this idea
·
Or even just a way to filter out changes made by someone else.