Settings and activity

2 results found

1. Prevent user from committing other user's changes

   79 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   3 comments  ·  SQL Source Control » Better Support for Shared Db Dev Model  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   Kendra 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 such as SQL Clone support this. With dedicated databases, each developer can have the version of objects which they need without worrying about whether someone else is changing things in the same database at the same time.

   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… more

   Anonymous supported this idea  ·  February 06, 2015

2. SQL Source Control Static Views (or Table Subsets using WHERE clause)

   636 votes

   Vote Vote Vote

   Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   1 vote 2 votes 3 votes Remove votes

   You have left! (?) (thinking…)
   30 comments  ·  SQL Source Control » Static Data  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close
   under review  ·  Kendra responded

   Hi everyone. I have merged some User Voice items on this topic of “filtered” static data, as there was significant overlap. I want to share our current guidance on handling scenarios where you need to version a subset of the columns and/or rows in the table.

   With SQL Source control, the best option at this point is to use a post-deployment script for this purpose.

   SQL Source Control introduced pre- and post- scripts in v6.3.

   A post-deployment script gives you a good amount of flexibility over exactly which rows or columns of data you want to include in your project. Example post-deployment scripts for static data are here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data

   If you make heavy use of Static Data, we have stronger support for this in SQL Change Automation.

   SQL Change Automation:

   • Supports column filtered static data tables in the SCA plugin in SSMS
   • Supports multiple post-deployment scripts, in case there is a preference to manage static data tables in dedicated post-deployment scripts
   • Allows approaches like bulk loading larger static data tables by supporting SQLCMD variables in migration and post-deployment scripts

   If there are other use cases where a migrations approach would add value to the team – such as easily being able to run data modification statements as part of deployments, or being able to customize the TSQL for schema changes – then changing from SQL Source Control to SQL Change Automation might make sense.

   Hi everyone. I have merged some User Voice items on this topic of “filtered” static data, as there was significant overlap. I want to share our current guidance on handling scenarios where you need to version a subset of the columns and/or rows in the table.

   With SQL Source control, the best option at this point is to use a post-deployment script for this purpose.

   SQL Source Control introduced pre- and post- scripts in v6.3.

   A post-deployment script gives you a good amount of flexibility over exactly which rows or columns of data you want to include in your project. Example post-deployment scripts for static data are here: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data

   If you make heavy use of Static Data, we have stronger support for this in SQL Change Automation.

   SQL Change Automation:

   • Supports column filtered static data tables in the SCA plugin in SSMS
   • Supports multiple post-deployment scripts, in case there is… more
   An error occurred while saving the comment
   Anonymous commented  ·  February 06, 2015  ·  Edit…  ·  Delete…

   Add a filter for static data, similar to the feature available in SQL Data Compare. This will facilitate source controlling data for tables that contain a mix of static system data and user content.

   Save Submitting...
   Anonymous supported this idea  ·  February 06, 2015