Settings and activity
10 results found
-
33 votes
An error occurred while saving the comment 
Adam
supported this idea
·
-
4 votes
An error occurred while saving the comment Adam
commented
-
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…
Adam
supported this idea
·
-
20 votes
An error occurred while saving the comment Adam
commented
Considering that the "lab environments match production environment" method is pretty standard these days it is hard to imagine other folks don't also have this problem. But I guess the votes don't lie. I may consider bribing for votes! hehe.
An error occurred while saving the comment Adam
commented
The server names are the same, the instance names are the same, the database names are the same; but they are in different fenced environments and each has a different IP. For example:
ServerA = 10.1.1.0 = Test environment
ServerA = 10.2.2.0 = Integration environment
ServerA = 10.3.3.0 = ProductionThen, in our "hosts" file, we have this entry:
10.1.1.0 ServerA.test
10.2.2.0 ServerA.int
10.3.3.0 ServerA.prodThat way, in SSMS (and other tools), I just connect to "ServerA.test", "ServerA.int", or "ServerA.prod" depending on which environment I need to hit. This thread may help, too - http://www.red-gate.com/MessageBoard/viewtopic.php?t=13026
Does that answer your question?
Adam
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.
An error occurred while saving the comment Adam
commented
I agree with the other comments on here. Associating it with a work item is great, but we also need to assign the other items (e.g. code reviewer) when checking in an item. These are often required by TFS and SQL Source Control just ignores those rules. Critical for us.
-
6 votes
-
47 votes
-
10 votesAdam
shared this idea
·
-
480 votes
Thank you everyone for your comments and votes on this over the years. While I don’t have a 100% full resolution for this suggestion, I can sum up our current recommendations here. Continued feedback is very welcome.
Our current recommendation is to use the post-deployment script feature of SQL Source Control (released in V6.3) to manage SQL Server Agent jobs.
An example script for this is here: https://documentation.red-gate.com/soc/common-tasks/working-with-pre-post-deployment-scripts/create-sql-server-agent-job
As some commenters in this thread have alluded to, it is possible (and sometimes very common) for SQL Agent jobs to have steps that touch multiple databases on a single SQL Server Instance. For this reason, some customers prefer to create a separate database for instance-level management and objects (sometimes named DBA or similar) and choose to manage things like linked servers and SQL Agent jobs with the post-script associated with that database.
This separate-database architecture also makes sense if the jobs…
Adam
supported this idea
·
An error occurred while saving the comment Adam
commented
and TFS, too please!
-
16 votes
I used this all the time, mostly because of Red Gate bugs, but not necessarily. We may not know we need a migration script until a change is checked in and deployed to the next environment (using SQL Compare). After the deployment, then I would see the need for a migration script (often because of a RG bug that wouldn't make a change correctly). Then I had to go back and create a migration script that SQL Compare could use for the deployment to the next environment.
Please bring this feature back.