Settings and activity
9 results found
-
10 votes
We have been working on v2 of Migrations, which stores migrations scripts in a table valued function within the database. This table valued function appears in the history. An Early Access Release of SQL Source Control is now available and can be downloaded from http://documentation.red-gate.com/display/MV2.
NOTE: This is an Early Access Release and is not fully tested or functionally complete yet. It would be great if you could try it in a test environment and let us know about your experiences so we can fix any issues and try to make any updates you need before the full release.
Thank you!
Stephanie Herr :-)
SQL Source Control Product Manager
Pete Cousins
supported this idea
·
-
9 votesPete Cousins
supported this idea
·
An error occurred while saving the comment -
7 votesPete Cousins
supported this idea
·
-
5 votesPete Cousins
supported this idea
·
An error occurred while saving the comment Pete Cousins
commented
This would be great. We always Ignore 'Users' permissions and role memberships' as users in live, test and UAT are different. We get into difficulties when we don't
-
189 votes
While SQL Source Control provides a way to view object history, it does require additional tooling to update your database to a specific version from history.
We currently have documentation on how this works here: https://documentation.red-gate.com/soc/common-tasks/update-to-a-revision-from-source-control
An error occurred while saving the comment Pete Cousins
commented
We created tags in SVN when creating a release. Much simpler than using revision numbers.
-
7 votesPete Cousins
supported this idea
·
-
19 votesPete Cousins
shared this idea
·
-
38 votes
An error occurred while saving the comment Pete Cousins
commented
If you're using database roles to control permissions to objects, this abstracts the permissions somewhat. However SCC includes the list of users in the role. Currently the only way around this is if the role is excluded from SCC. Personally, as a DBA, I prefer the permissions to be in SCC, as it's up to the developers to decide who should have access to what objects.
-
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…
Pete Cousins
supported this idea
·
We always filter users as there are different users in different environments. We have problems when developers forget to do this. This improvement would be great.