Settings and activity
8 results found
-
4 votes
Mark.Moore
supported this idea
·
-
33 votesMark.Moore
supported this idea
·
-
22 votesMark.Moore
supported this idea
·
-
57 votes
An error occurred while saving the comment Mark.Moore
supported this idea
·
-
254 votes
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…
Mark.Moore
supported this idea
·
- Supports column filtered static data tables in the SCA plugin in SSMS
-
633 votes
Hi,
We just added this capability to Flyway, which is our x-database, x-OS cloud- and Git-first Database DevOps solution for versioning and deploying database changes. You can learn more about this feature in Flyway at https://documentation.red-gate.com/fd/working-with-data-138347109.html#Workingwithdata-Controllingstaticdata.
You can also import your SQL Source Control repos into Flyway while keeping your Git history. Learn more about moving to Flyway and importing your project at https://documentation.red-gate.com/fd/transitioning-from-other-redgate-tools-164167855.html.
If you have any questions, please comment below or reach out to us at DatabaseDevOps@red-gate.com.
Thank you!
Stephanie Herr
Product Manager - Database DevOps
Mark.Moore
supported this idea
·
-
7 votesMark.Moore
supported this idea
·
-
90 votesMark.Moore
supported this idea
·
It's been 5+ years since this has been asked for. I can't believe there is no response from Redgate about this improvement. Labeling our code is an important part of our process. It allows us to branch for hot fixes, compare at a release, etc. Having to go look up where we labeled, get the date/time and then come back in to redgates history viewer and pick the correct item has already show it's a problem as it can cause mistakes.