Skip to content
← Customer Feedback for Redgate

Settings and activity

4 results found

  1. Create an option to use MERGE INTO versus insert, update, delete

    35 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…)
    1 comment  ·  SQL Data Compare  ·  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
    Valthor Druzin supported this idea  · 

  2. add If not exists to data compare

    225 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…)
    18 comments  ·  SQL Data Compare  ·  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
    Valthor Druzin commented  · 

    Any progress on this issue ?

    Valthor Druzin supported this idea  · 

  3. 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…

    Valthor Druzin supported this idea  · 

  4. Support different static data per customer

    254 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…)
    6 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 all. Thank you for your votes and feedback on this issue over the years. Here is our current guidance for this suggestion:

    Post-deployment scripts give you flexibility for static data

    With SQL Source Control, you can now use a post-deployment script to “dynamically” deploy static data based on a factor such as @@SERVERNAME or other query-able conditions.

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

    An example post-deployment script which shows how to control deployment of static data by environment is 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 a preference to manage static data tables in dedicated post-deployment scripts
    • Allows approaches like bulk loading larger static data tables by supporting SQLCMD…
    An error occurred while saving the comment
    Valthor Druzin commented  · 

    A simple solution to this would be if SSC would have the option that the user could pick the check-in folder for the data explicitly, allowing for the option to make the data location different from the location of the objects. This way you could actually have the same database structure but different data for each customer, whilst maintaining a simple branching strategy within your version control subsystem.

    Valthor Druzin supported this idea  ·