Skip to content
← Customer Feedback for Redgate

Settings and activity

2 results found

  1. Allow me to specify what tables to sync instead of a Database

    5 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…)
    4 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
    AdminRedgate Administrator (Admin, Redgate) responded

    In v2.2, which is expected to be released in the next few weeks, we’ve implemented Object Filtering, which allows you to specify which objects to inlcude/exclude for source control. Therefore, you could link a database and set up a filter so that only the tables/procedures your interested in for your project would be source controlled. Would this help?
    You can get the v2.2 Release Candidate at http://www.red-gate.com/messageboard/viewtopic.php?t=13668 to try this out.

    An error occurred while saving the comment
    Afroz commented  · 

    I am sorry I must mention ApplicationA and ApplicationB not Projects. I am aware that this is not a good practice to have two applications to have ddl on same database but they touch distinct tables in the same database. these are the legacy apps we have. we see potential for all the new apps with SQL Source but legacy apps are pain. Conceptually if a database can have multiple links link1, link2.. this will solve our problem

    An error occurred while saving the comment
    Afroz commented  · 

    This is very helpful, but can one sync one database to more than one project in source control? I don't think this feature is available today. Lets say Database Widgets has two objects 1 and 2. I want to be able to save object 1 to ProjectA in source control and 2 to ProjectB in source control.

    Afroz shared 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…

    Afroz supported this idea  ·