Settings and activity
10 results found
-
131 votesptrubs supported this idea ·
-
131 votesptrubs supported this idea ·
-
135 votes
Hi – this request was closed when the ‘TFS work items’ feature was released. http://documentation.red-gate.com/display/SOC3/Committing+changes
However, we’re still hearing about this enough that I’d agree with commenter Ben: it should be reopened.
We will continue to gauge interest here on UserVoice. Please do tell us more in the comments about what you expect to be able to do with Work Items in SQL Source Control.
ptrubs supported this idea · -
207 votesptrubs supported this idea ·
-
8 votes
An error occurred while saving the comment ptrubs supported this idea · -
4 votes
An error occurred while saving the comment -
10 votesptrubs shared this idea ·
-
4 votes
An error occurred while saving the comment ptrubs commentedYou could also manage linked servers via synonyms, which gives your procs/views the same code in all environments, and you can manage your synonyms outside the deployment process
(but sqlcmd would make a LOT of other use cases much simpler)
-
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…
ptrubs 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.
ptrubs supported this idea ·
this is a duplicate of https://redgate.uservoice.com/forums/141379-sql-compare/suggestions/39117337-it-would-be-helpful-to-provide-the-capability-to-e