User profile for mattcomroe

Hi Chris, Thanks so much for your prompt reply. I actually discovered a pretty great workaround. In a situation like from my first post, where there are additional schema objects that SSC will want to try and add on the "Commit Changes" tab, I can just Ctrl+A to select them all, right-click and chose "Undo Changes...", and that will allow me to delete any new objects because SSC regards them as object changes. Of course, our devs will have to do this as part of their initial setup and not after they've made changes in order to not lose any "real" schema changes that are made. Problem solved! Again, thanks so much to you and James for your help on this. / comments

Hi Chris, Thanks so much for your prompt reply. I actually discovered a pretty great workaround. In a situation like from my first post, where there are additional schema objects that SSC will want...

0 votes

Hi James, Thank you for your reply. Yes, I think you're understanding my issue correctly in terms of what I'm testing out and what my expectations are. I understand why the Transients folder works the way it does, but let me describe a workflow scenario which my company is going to encounter, and see if possibly there is an workaround. All our developers have a seat license for SSC, but we only have one license for the SQL Toolbelt for our build machine, specifically so we can have SQL Compare 10 and SQL Data Compare 9 with their command line tools in order to have a Continuous Integration environment. A developer checks in a change, and an automated build process kicks off which gets latest from SVN, builds and deploys code, and runs a SQL Compare and DataCompare command line batch to update a couple of different staging databases. Our production environment has quite a few customer databases, all of which are *supposed* to be the same schema, but without a great process in the previous years they have gotten crufty and are not in sync. We will get bug tickets which are data-specific, so we will pull down a copy of their particular database and fix the bug using that. My concern is that a developer will do this: - Compare bugfix branch in SVN to copy of customer database in order to try and sync schemas. This will not show any additional objects which are in that target DB as being designated for drops. - Dev makes fix, and on checkin inadvertently adds crufty additional schema objects into SVN. - Extra objects make their way into the source tree. I realize it's the responsibility of our developers to recognize which changes are actually theirs upon checking in (even though we're going with the "dedicated database" method with SSC), but I was hoping to remove potential issues. Further, I know that the "right" answer is to pull down each production database and run SQL Compare 10 against them in order to properly sync schemas, but that requires lots of time for regression testing that I'm not allowed to have right now. We're just trying to get our Red Gate-fueled CI environment up and running, and I'm trying to prevent stumbles before they happen. [image] / comments

Hi James, Thank you for your reply. Yes, I think you're understanding my issue correctly in terms of what I'm testing out and what my expectations are. I understand why the Transients folder works ...

0 votes

SQL Source Control is not trying to drop extra objects

Here's my scenario: I created a baseline project in SVN using SSC. I link it to a different database with a slightly different schema, including some extra objects which exist in the target DB and ...

3 followers 5 comments 0 votes

How can we help you today?

mattcomroe

Activity overview