Settings and activity
11 results found
-
1 vote
doug shared this idea ·
-
34 votes
An error occurred while saving the comment -
5 votes
-
13 votes
-
94 votes
As we noted in https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/2299881-migrations-support-for-git-mercurial, we have stopped work on Migrations v2 beta.
Unfortunately, there are currently no plans to include migration script rollbacks alongside the forward migration scripts, but we are still watching this request with interest.
An error occurred while saving the comment Sadly this is amazingly easy when using Code First in EF6, with a simple 'up'/ 'down' migration file. Which also means that all your SQL version control is now with your code and Red-Gate becomes every more irrelevant. So there is going to be a group of dinosaurs that are stuck in the SQL server realm and youngsters who just use whatever EF can connect to. Sure a EF6 query can take 600ms to run versa the same hand coded ado query being 40ms, but customers want faster code delivery and developer productivity, not faster execution.
It is a shame that Red-Gate is still living in the past somewhat :( -
215 votes
-
156 votes
-
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.
-
215 votes
-
14 votes
-
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…
this is free with https://www.ssmstoolspack.com/Features