Skip to content
← Customer Feedback for Redgate

Settings and activity

5 results found

  1. WITH ENCRYPTION stored procedures cannot be edited

    10 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…)
    2 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
    Len Kalman commented  · 

    Sadly there is not an option to ignore the WITH ENCRYPTION parameter when performing a comparison.

    This has been added the details of this support call to an existing feature request whose reference is SC-4419.
    Just looking for more users who complain about this

    An error occurred while saving the comment
    Len Kalman commented  · 

    I'm attempting to compare our development database vs a production database. When we deploy to production we set SQL Encryption on for all views, procedures, functions and triggers. With SQL Compare its showing that every view, procedure, function and trigger is modified, just because the production side has "WITH ENCRYPTION" for the objects. This forces us to manually evaluate the 1500+ objects that are encrypted to see if anything else has changed.

  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
    Len Kalman supported this idea  · 
    An error occurred while saving the comment
    Len Kalman commented  · 

    Just Checking Status on this request SDC-828.

    Len Kalman shared this idea  · 

  3. Do not check all the items to be committed by default

    13 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…)
    0 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
    Len Kalman supported this idea  · 

  4. Move Column Order

    2 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…)
    0 comments  ·  SQL Source Control » Better Support for Shared Db Dev Model  ·  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
    Len Kalman shared this idea  · 

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

    Len Kalman supported this idea  ·