Settings and activity
19 results found
-
20 votes
Steve Jones
supported this idea
·
-
22 votesSteve Jones
supported this idea
·
-
15 votesSteve Jones
shared this idea
·
-
3 votes
An error occurred while saving the comment -
13 votesSteve Jones
shared this idea
·
-
6 votesSteve Jones
supported this idea
·
-
6 votesSteve Jones
shared this idea
·
-
16 votes
An error occurred while saving the comment Steve Jones
commented
I'd add that I'd like 3 folders. Default, personal, team. I would like the ability to have team override personal, override defaults.
Steve Jones
supported this idea
·
-
131 votes
-
15 votesSteve Jones
supported this idea
·
-
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…Steve Jones
supported this idea
·
An error occurred while saving the comment Steve Jones
commented
When storing the data items in files, it would be good to keep everything in PK order so that changes are easier to spot. Historical order is less important when working with static data.
-
16 votesSteve Jones
supported this idea
·
-
6 votes
An error occurred while saving the comment Steve Jones
commented
If this is configurable, it's OK. For me, when I commit, often I want multiple items together. I think unchecking works better for me.
-
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…
Steve Jones
supported this idea
·
-
4 votes
Another trick is to use your mouse to select all the rows and then Keep Mine/Take Theirs will apply to all the highlighted rows.
I hope this helps!
Steve Jones
supported this idea
·
-
3 votesSteve Jones
supported this idea
·
-
6 votesSteve Jones
supported this idea
·
-
79 votesSteve Jones
shared this idea
·
-
4 votesSteve Jones
supported this idea
·
If this is your agent path being quite long, perhaps you could revisit that portion of your infrastructure? While I do agree that a shorter name might be useful here, I don't know if we want to make the change to the product here. I realize that moving localdb can be disruptive as well, so I am curious as to what path you used or have that causes the issue.