Settings and activity
9 results found
-
344 votesPete Cousins supported this idea ·
-
153 votesPete Cousins supported this idea ·
-
212 votesPete Cousins supported this idea ·
-
75 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…
An error occurred while saving the comment Pete Cousins commentedThis can already be done. Script the SQL Agent Job from SSMS (amend script so it drops existing by name, and not job_id), save the file, and add it into to SVN. I have a seperate folder under Trunk called SQLAgentJobs.
We also use VisualSVN (http://www.visualsvn.com/) to version control SSIS packages & SSRS reports using SVN too. -
4 votes
An error occurred while saving the comment Pete Cousins commentedI don't think this is a Redgate problem - it's an environment problem. I have 3 servers, dev-sql-db02, mo-sql-db02 & rias-sql-db02. Development, test and live versions of the same server. On other servers, I have linked servers to all these machines called SQL-DB02. In a dev environment this links to DEV-SQL-DB02, on test to MO-SQL-DB02 etc. As code moves from dev to test to production, there's no need to change it, as the SQL-DB02 linked server points to the appropriate server.
-
76 votesPete Cousins supported this idea ·
-
12 votesPete Cousins supported this idea ·
-
79 votesKendra responded
An update for users on the status of this suggestion:
An ‘object locking’ feature was added to SQL Source Control following the creation of this item which can helps users working in a shared database environment not write over each other’s changes.
This may help prevent accidental commits in some cases, as there is a “Locking” tab which allows users to see which other users are working on specific items.
Locked items are still eligible to be committed, however, and there are cases where users will want to commit an item — perhaps to a specific branch in source control which is not ready to deploy — even if the item in the database is locked.
We have found at Redgate that the easiest way to enable alignment with distributed source control systems such as Git is to empower users to use dedicated development databases rather than shared databases. Tools…
Pete Cousins supported this idea ·
If you're using SVN for your repository, have a look at VisualSVN http://www.visualsvn.com/