Settings and activity
2 results found
-
12 votes
An error occurred while saving the comment -
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…
Bret Lowery supported this idea ·An error occurred while saving the comment Bret Lowery commentedDitto TFS
Stephanie, it's not possible in the case of startup procs (procs in master flagged as startup by sp_procoption). These may be executed while user databases are still in recovery after a cold restart or cluster failover. Other than that one case though I think you are correct.