Settings and activity

2 results found

  1. 254 votes
    How important is this to you?
    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
    Dan Carlstedt supported this idea  · 
  2. 12 votes
    How important is this to you?
    An error occurred while saving the comment
    Dan Carlstedt commented  · 

    Adding both options would be best IMO. Our main use case is for when we need to source control a certain set of object but we don't when them to be deployed to all of our databases. Our deployment is using this same filter.

    Dan Carlstedt supported this idea  ·