Settings and activity
12 results found
-
18 votes
Chattabaugh
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…
Chattabaugh
supported this idea
·
-
7 votesChattabaugh
supported this idea
·
-
12 votes
An error occurred while saving the comment Chattabaugh
supported this idea
·
-
20 votes
-
7 votesChattabaugh
supported this idea
·
-
200 votes
Kendra
responded
While SQL Source Control does not currently provide a simple way to right click and ‘Undo’ static data changes on the ‘Commit’ screen as suggested, there is a workaround which may help some users.
If you wish to revert the static data in the table to a previous version which you have committed, you can do this by viewing the history of commits for the object in SQL Source Control, and then launching SQL Data Compare to update the database.
Please note that this workaround requires a license for Data Compare. More detail on how to do this are here: https://documentation.red-gate.com/soc/common-tasks/update-to-a-revision-from-source-control
-
4 votes
-
35 votes
For now, enter your BugID into the comment field when you commit changes.
Please continue to vote/comment here if you would like to see a seperate Bug ID box like TSVN has. See James’ comment for more details.
-
131 votes
-
22 votesChattabaugh
supported this idea
·
-
15 votes
Having the ability to use post-deploy migration scripts could eliminate a lot of custom DDL scripting. For example: Adding a new table or column often requires seeding seeding with data. Pre-deploy scripts require adding the DDL changes to the script. Post deploy would only need the data changes.