Settings and activity
3 results found
-
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.
An error occurred while saving the comment -
10 votes
An error occurred while saving the comment 
Marbry
commented
This makes a lot of sense, and was initially how I thought the "shared" model worked. We created a standard location in TFS for the repository, so we can at least know where to link it to.
It also makes developers who are somewhat resistant to using new products, however easy to use, less liable to actually utilize it if they have to manually add each DB themselves. A minimal change to workflow would help to ease the transition.
If someone else adds a shared DB to source control, I should really be able to see that as being under source control without having to do anything else myself I would think. It would be very useful to at least have this option.
Marbry
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…
An error occurred while saving the comment Marbry
commented
This would bevery useful, jobs (searchable would be great) in TFS.
It's currently a real pain keep track of all that once you accumulate any number of production jobs.
Was this ever added? It was one of the big usability holes for us since everyone would have to manually add 100+ DB's themselves.
If you're shared, have SQL source control installed, I would want the DB to show as under source control in SSMS by default.