Settings and activity
7 results found
-
8 votes
An error occurred while saving the comment 
John Q Martin (@SQLServerMonkey)
supported this idea
·
-
35 votesJohn Q Martin (@SQLServerMonkey)
shared this idea
·
-
74 votesJohn Q Martin (@SQLServerMonkey)
supported this idea
·
-
15 votes
An error occurred while saving the comment John Q Martin (@SQLServerMonkey)
commented
After reading in the documentation that I need to manually create the database and then alter the configuration file, I have to ask why this is not dealt with when the shared database is linked to source control. The ability to track who is making changes is a fundamental requirement in this model so the use of TempDB has to be seen as inappropriate.
I would suggest that also rather than having a single control database on the instance/server that perhaps it would be a better model to have a configuration database per-database that is linked to using the shared model. That way it is clear what it is for and that it is operating in shared mode.
Many thanks
JQ
John Q Martin (@SQLServerMonkey)
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…
John Q Martin (@SQLServerMonkey)
supported this idea
·
-
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
-
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.
An error occurred while saving the comment John Q Martin (@SQLServerMonkey)
commented
I have the same request, we have a large development team and are going to be migrating to use SQL Source Control. We will be using the Shared development model and it would be really useful to not get the developers to link each database on the various servers.
Rather if they can just open management studio and then the Source Control plugin picks up which databases are under source control and sets up the plugin as required.
Many thanks
John Q Martin (@SQLServerMonkey)
supported this idea
·
Personally not too bothered, just the ability to select the database would be great. Drop down would be in keeping with SSMS, Alternatively can you link it to the database drop down already in SSMS to handle the linking for the session window?