Skip to content

Settings and activity

1 result found

  1. 636 votes
    Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    You have left! (?) (thinking…)
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
    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…
    An error occurred while saving the comment
    Jason Duffett commented  · 

    The problem we have is that the current EAP builds of SQL Source Control aren't usable because of the limited data support.

    We use the tools in the following way:
    1. A single SVN repository
    2. SQL Source Control for developers to check-in changes to this source tree.
    3. Custom SQL Compare and SQL Data Compare scripts to deploy changes from the repository to our test, staging, production environments

    Testing we've done with the pre-release SQL Source Control have failed because it always tries to overwrite the data in the repository.
    We won't be able to use the new release unless either we can completely disable data support in SQL Source Control, or the data support is enhanced to allow us to specify which columns to source-control.

    Jason Duffett supported this idea  ·