Activity overview
Latest activity by atwebb
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. / comments
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...
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 ScriptGet a warning that I should include all dep...
Whew, ok, so, I'd done a build or two and release prior, then installed SQLTest/SQLCop and decided to see if it would roll through the release management but it didn't. I added my own test schema (UnitTest) and it didn't, that's when I went down this rabbit hole and opened this comment.
Turns out, there's a default option for IgnoreTSQLT in the build (in the XML config file that's generated), I added the -IgnoreTSQLT switch to my release SQL Compare Options and bam, it all went through. Interesting that my own schema was ignored, I'm guessing because it contains that word "test".
Thanks for the help! / comments
Whew, ok, so, I'd done a build or two and release prior, then installed SQLTest/SQLCop and decided to see if it would roll through the release management but it didn't. I added my own test schema (...
The filter.scpf file in source control is correct, the one in my nuget package is empty, it has includes and I'm assuming it's not comparing anything, thus not generating a script. I had left everything as default assuming it would grab the Filter file automatically for comparisons. / comments
The filter.scpf file in source control is correct, the one in my nuget package is empty, it has includes and I'm assuming it's not comparing anything, thus not generating a script. I had left every...
Little bit more info, it appears the disconnect is in the Deploy Release step, the release is setup and has the source/targer files (and they differ). Update.sql says:
This script is empty because the Target and Source schemas are equivalent after applying the filter in package file
Seems pretty straightforward but the filters are really, really low and don't contain procs/schemas that should not be promoted/excluded. / comments
Little bit more info, it appears the disconnect is in the Deploy Release step, the release is setup and has the source/targer files (and they differ). Update.sql says:
This script is empty because ...
Nothing's a silly question except maybe mine [image]
They are in different states, I've validated with SQL Compare and checked that the logs are pointing to the correct targets.
Steps for build:
DLM Build from latest SOC version to Package
I can validate that the generated package is good (has the changes I want)
Release
DLM Release (both from package and create database release) will show that they're comparing against my target DB and both end up showing the no updates. I got one or two to work and if I make a migration script then it works but it won't transfer state, these are new procs so I'd expect it to be the easiest scenario. I'm sure I'm missing something simple. / comments
Nothing's a silly question except maybe mine
They are in different states, I've validated with SQL Compare and checked that the logs are pointing to the correct targets.
Steps for build:
DLM Build...