Settings and activity
6 results found
-
530 votes
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…An error occurred while saving the comment 
Anonymous
supported this idea
·
-
636 votes
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…
Anonymous
supported this idea
·
-
83 votesAnonymous
supported this idea
·
-
17 votesAnonymous
supported this idea
·
-
34 votesAnonymous
supported this idea
·
-
476 votes
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.
Anonymous
supported this idea
·
An error occurred while saving the comment Anonymous
commented
a command line option to setup linked dbs would be most effencient for our process
The lack of improvement in this area makes merging of static data a complete nightmare! A recent merge took 7 days primarily due to data merge issues, when the code part was a few hours!!
I think the compare key should also be highlighted somehow, perhaps in a block comment BEFORE the INSERT statement, so that it is used for matching rows (can create a regex for that in beyond compare)
THis has got to be fixed before I find some alternative tooling to make branch merges take a sensible time.