When creating a migration script, where is the option to uncheck Commit All Dependencies?

Howdy! I'm aware of the migration scripts and have been using them to great success however I have an issue:

Committing 2 stored procs, hit Generate Script
Get a warning that I should include all dependencies
I don't want to (and don't need to) BUT the check box to ignore them is grey out.

If I select the ? box I get this:

By default, SQL Source Control includes these objects in the commit. To exclude them, clear the Commit all dependencies check box.

Where is that check box? I can't find that option anywhere, thanks!



Tagged:

Answers

  • turbopockyturbopocky Posts: 5 New member
    I'd like to know how to uncheck it as well, since it causes a crash:
    Can't select dependency RedGate.SQLSourceControl.Engine.Diff.IDifferences.ConflictedSchemaDifference

  • Sergio RSergio R Posts: 610 Rose Gold 5
    Hi,

    When using migration scripts it is not possible to disable  the include all dependencies checkbox, this is by design as not doing so would result in issues.

    Thank you,
    Sergio
    Product Support Engineer
    Redgate Software Ltd
    Please see our Help Center for detailed guides on how to use our tools
  • turbopockyturbopocky Posts: 5 New member
    I wouldn't be trying to uncheck it if it wasn't crashing. I can't even use migration scripts at all right now. I've submitted a couple of crash reports yesterday and I hope it can get fixed soon.
  • atwebbatwebb Posts: 7 New member
    I sent a similar response in my support ticket where it was mentioned the the box still existing on migration scripts was an oversight.

    This is a necessary function when working in a shared database environment. You easily end up with an object that can be used by two or more developers. You are forced to check in and associate changes from an associated object (sometimes through a view/abstraction layer) when you really, really don't want to and it would be fine to check in the pending changes without the dependencies.

    I believe it should be an option, leaving as an option similar to the regular state based check in allows the team to have granular control. It's already made clear in the modal that there could be issues and you need to be sure. At this point, we have no control over what SOC considers a dependency vs what actually needs to be committed.

    I can see difference for a dedicated model but shared will inherently need to be decoupled, at least in how I see the product.

    Thanks for the support responses! We still love the products and all.
Sign In or Register to comment.