Settings and activity

1 result found

1. Support different static data per customer

   254 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   6 comments  ·  SQL Source Control » Static Data  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   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 variables in migration and post-deployment scripts

   If there are other use cases where a migrations approach would add value to the team – such as easily being able to run data modification statements as part of deployments, or being able to customize the TSQL for schema changes – then changing from SQL Source Control to SQL Change Automation makes sense.

   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… more
   Tim Climis supported this idea  ·  Jan 19, 2016
   An error occurred while saving the comment
   Tim Climis commented  ·  Jan 19, 2016  ·  Edit…  ·  Delete…

   We'd also like this, not so much for storing different customer's data, but for storing test data. Our main repo stores code tables, and other static data. But it would nice to have a separate data folder for unit test data - the database schema would obviously be the same, but the tracked testing data would contain data that is normally dynamic for predictable test results.

   Save Submitting...