Settings and activity

6 results found

1. Command line tool (or API) for SQL Source Control Integration

   476 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…)
   64 comments  ·  SQL Source Control  ·  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

   Thank you everyone for the suggestions and votes for this over the years.

   I’d like to surface up a workaround for the “linking” problem which is mentioned in the comments. For the use case of easing pains around environment setup with a large number of databases, we have had customers find success using code based off Alessandro Alpi’s blog post: https://alessandroalpi.blog/2016/06/28/automatically-link-databases-to-red-gate-sql-source-control/

   I do understand that this is a broader issue and hear that many of you also want command line or API support for the product in general.

   If there are specific scenarios or workflows that would be useful to automate for you, this feedback is also very useful, and if you have details on the type of VCS you use and the workflow (such as a branching model) that it would fit in to, that would be very helpful for us to hear as well.

   David Canning supported this idea  ·  Mar 29, 2016

2. Undo data changes

   200 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…)
   8 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
   Kendra responded

   While SQL Source Control does not currently provide a simple way to right click and ‘Undo’ static data changes on the ‘Commit’ screen as suggested, there is a workaround which may help some users.

   If you wish to revert the static data in the table to a previous version which you have committed, you can do this by viewing the history of commits for the object in SQL Source Control, and then launching SQL Data Compare to update the database.

   Please note that this workaround requires a license for Data Compare. More detail on how to do this are here: https://documentation.red-gate.com/soc/common-tasks/update-to-a-revision-from-source-control

   David Canning supported this idea  ·  Mar 29, 2016

3. 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
   David Canning supported this idea  ·  Mar 29, 2016

4. Make SQL Data Easier to Merge (Static Data)

   530 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…)
   37 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

   Thanks for this suggestion and for the many comments and upvotes. I realize that this is a pain point.

   I have a few shorter-term workarounds to summarize as well as some information on the longer roadmap in this update. I know these shorter-term workarounds aren’t perfect (I summarize the pros and cons), but I’m posting them as they may help a few folks.

   Workaround 1) When data changes to static data need to be made, use a “relink the table” pattern
   One can “cleanly rescript” a static data table in SQL Source Control by:

   • Unlinking the static data table
   • Committing
   • Relinking the static data table
   • Committing

   Pro: This works with the GUI and requires no special knowledge or comfort with TSQL. This may help folks with just a few static data tables.
   Con: This requires extra steps and results in extra commits in the history, which I realize can be annoying, particularly if the team doesn’t squash commit history when merging or do similar things.

   Workaround 2) Use a post-deployment script to manage static data tables instead of linking them
   Another option is to not use the “link static data tables” feature at all, and instead manage the static data table yourself with a custom script.

   I’ve added a code sample called “post-deployment script to manage static data for a table with an identity column” into our reference on post-deployment scripts: https://documentation.red-gate.com/soc7/common-tasks/working-with-pre-post-deployment-scripts/static-data

   Pro: This gives you complete control over the TSQL.

   Con: Your post-deployment script might become quite complex and create its own issue in merge conflicts, depending on how many static data tables you have and whether you are using the post-deployment script for other things.

   An alternate approach using SQL Change Automation
   If customers have licenses for SQL Change Automation, the SCA Migrations approach does not have this issue and has additional features for flexibility with static data:

   • Since migrations only script out the data which has changed, this scripting issue of the entire table doesn’t occur in SCA – it only ever needs to generate commands for what has been modified since the last migration
   • 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.

   Roadmap
   I’ve chatted with our engineering teams and Redgate does have the desire to better support this scenario longer term. This is not a “quick fix” scenario and will likely require a rethinking of the way static data is managed within the tool.

   While the “rethinking” bit of this has begun, we don’t specifically have this on the SQL Source Control roadmap (https://www.red-gate.com/products/sql-development/sql-source-control/roadmap) at this point. We do have improved support for use with Git feature branches as a future candidate on the roadmap, and we do know from research with many customers that static data is quite important to folks. While I can’t make any promises, I think we are likely to be able to offer an improvement in this area.

   Thanks for this suggestion and for the many comments and upvotes. I realize that this is a pain point.

   I have a few shorter-term workarounds to summarize as well as some information on the longer roadmap in this update. I know these shorter-term workarounds aren’t perfect (I summarize the pros and cons), but I’m posting them as they may help a few folks.

   Workaround 1) When data changes to static data need to be made, use a “relink the table” pattern
   One can “cleanly rescript” a static data table in SQL Source Control by:

   • Unlinking the static data table
   • Committing
   • Relinking the static data table
   • Committing

   Pro: This works with the GUI and requires no special knowledge or comfort with TSQL. This may help folks with just a few static data tables.
   Con: This requires extra steps and results in extra commits in the history, which I realize can… more

   David Canning supported this idea  ·  Mar 29, 2016

5. Include Ad Hoc Scripts in SQL Source Control

   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…)
   7 comments  ·  SQL Source Control  ·  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
   An error occurred while saving the comment
   David Canning commented  ·  Mar 29, 2016  ·  Edit…  ·  Delete…

   You can add them through your VCS system outside of SQL Source Control

   Save Submitting...

6. Link/Unlink Static Data - change to non-modal dialog

   11 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…)
   0 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
   David Canning supported this idea  ·  Mar 29, 2016