Settings and activity
9 results found
-
7 votes
Wesley Smith
shared this idea
·
-
20 votes
Our current guidance for rollback support on SQL Change Automation is here: https://documentation.red-gate.com/sca/developing-databases/concepts/advanced-concepts/rollbacks
Our roadmap for 2021 does include further researching and evolving rollback procedures: https://www.red-gate.com/products/redgate-deploy/roadmap
Wesley Smith
supported this idea
·
-
16 votes
An error occurred while saving the comment Wesley Smith
shared this idea
·
-
1 voteWesley Smith
shared this idea
·
-
9 votesWesley Smith
shared this idea
·
-
3 votesWesley Smith
shared this idea
·
-
135 votes
Hi – this request was closed when the ‘TFS work items’ feature was released. http://documentation.red-gate.com/display/SOC3/Committing+changes
However, we’re still hearing about this enough that I’d agree with commenter Ben: it should be reopened.
We will continue to gauge interest here on UserVoice. Please do tell us more in the comments about what you expect to be able to do with Work Items in SQL Source Control.
-
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
Wesley Smith
supported this idea
·
-
47 votesWesley Smith
supported this idea
·
David,
SQL Source control generates code that checks @@ERROR after each statement and inserts into #tmpErrors when an error occurs. This is then used at the end of the script to decide to COMMIT the transaction.
The migration script doesn't have that code after each statement. So, if some operation of the migration script were to fail, the SQL Source control doesn't know about the error and will just continue to the end of the script, where it will commit the changes. I'd like some way for the script to detect an error in the migration script and not commit.