Settings and activity
6 results found
-
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
An error occurred while saving the comment 
Timothy Batts
supported this idea
·
-
477 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.