Skip to content
← Customer Feedback for Redgate

Settings and activity

5 results found

  1. Improve performance over remote connections

    24 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    3 comments  ·  SQL Source Control  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    An error occurred while saving the comment
    Jason commented  · 

    This is crucial for our organization to get adoption by our offsite and overseas developers. I posted some findings in the forums that I hope will help:

    http://www.red-gate.com/MessageBoard/viewtopic.php?t=16521

    Jason supported this idea  · 

  2. Agent jobs

    480 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    31 comments  ·  SQL Source Control  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    under review  ·  Kendra responded

    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…

    Jason supported this idea  · 

  3. Undo data changes

    200 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    8 comments  ·  SQL Source Control » Static Data  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Kendra responded

    While SQL Source Control does not currently provide a simple way to right click and ‘Undo’ static data changes on the ‘Commit’ screen as suggested, there is a workaround which may help some users.

    If you wish to revert the static data in the table to a previous version which you have committed, you can do this by viewing the history of commits for the object in SQL Source Control, and then launching SQL Data Compare to update the database.

    Please note that this workaround requires a license for Data Compare. More detail on how to do this are here: https://documentation.red-gate.com/soc/common-tasks/update-to-a-revision-from-source-control

    Jason supported this idea  · 

  4. Improved object merge support - Provide ability to merge a conflicted object, instead of just Keep Mine or Take Theirs

    131 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    under review  ·  20 comments  ·  SQL Source Control  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    Jason supported this idea  · 

  5. SQL Source Control Static Views (or Table Subsets using WHERE clause)

    636 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    You have left! (?) (thinking…)
    30 comments  ·  SQL Source Control » Static Data  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback
    Signed in as (Sign out)
    Close
    Close
    under review  ·  Kendra responded

    Hi everyone. I have merged some User Voice items on this topic of “filtered” static data, as there was significant overlap. I want to share our current guidance on handling scenarios where you need to version a subset of the columns and/or rows in the table.

    With SQL Source control, the best option at this point is to use a post-deployment script for this purpose.

    SQL Source Control introduced pre- and post- scripts in v6.3.

    A post-deployment script gives you a good amount of flexibility over exactly which rows or columns of data you want to include in your project. Example post-deployment scripts for static data are here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data

    If you make heavy use of Static Data, we have stronger support for this in SQL Change Automation.

    SQL Change Automation:

    • Supports column filtered static data tables in the SCA plugin in SSMS
    • Supports multiple post-deployment scripts, in case there is…
    Jason supported this idea  ·