Settings and activity
6 results found
-
636 votes
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 
Timothy Batts
supported this idea
·
-
480 votes
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…
Timothy Batts
supported this idea
·
-
40 votes
An error occurred while saving the comment Timothy Batts
commented
This should be default behavior when using source control as a source. It should only compare the tables that are actually included in linked data in source control
Timothy Batts
supported this idea
·
-
9 votesTimothy Batts
shared this idea
·
-
12 votes
An error occurred while saving the comment Timothy Batts
commented
I've noticed this with testing the Migrations v2. I do not agree with the concept of always executing all migration scripts first. It is possible that in a staging or production environment that several different changesets are included in a single release. There may have been changes in one minor release that affected an object, and then further changes later in another changeset that require a custom migration script. V1 was very good about determining order of operations based on the order the changes were checked in to source control. With v2 there is no option to determine order of operations, and the later migration script changes can be executed prior to earlier non-migration script changes being applied.
Yes, you can script pre-conditions so that the migration script only executes when the database schema is in the correct state, and can even script to create the necessary schema objects as part of your migration script. But we could do that 10 years ago already with a simple handwritten script.
A big part of the value of Red-Gate tools for us has always been the ability to reduce the manual work in scripting trivial items such as adding tables and columns, etc. and letting the comparison apis do that for us, focusing our attention on custom scripting that needs to be done to maintain the correct state of existing data. With the "execute first" mandate of the migrations v2, in my opinion this is a step backward.
Timothy Batts
supported this idea
·
-
6 votesTimothy Batts
shared this idea
·
I was thinking extending the UI for data changes to function more like Data Compare would be nice, where you have inserts, updates, and deletes, and you can check only the rows you wish to change in source control.
This would also be helpful in shared development scenarios, where multiple developers may have changes to static rows in the same table for different work items. This way they can check in only their own changes individually and link them to the respective work items they actually belong to.