• sgmunson - Thursday, September 13, 2018 9:15 AM

    Just sayin', but wouldn't the continued use of such a product create a dangerous dependency  that's probably worse than violation of naming standards or other needs that would normally dictate a database object change?   Aren't you effectively  pushing the problem off into a cubby hole and making yourself dangerously dependent on said cubby hole?   I'd be afraid to adopt it because if it ever broke, I'd be up you know what creek without any means of making it work.

    I don't want to get into whether or not this tool is good (it's a direct competitor to Redgate tools, so... you're on your own as to what features you should add or improve, sorry), but I will say, you have a bit of a point about becoming dependent on a tool. However, the key point is not the dependency. It's the efficiency that you get from it. I mean, if you use our SQL Change Automation tool (no links, I'll play nice), you're building a dependency around that tool, yes, but you're gaining massive improvements in your ability to deploy databases, faster, safer, more frequently... I'm not seeing a problem here. Same thing goes if you get a monitoring tool, or anything other than ONLY EVER building your own stuff. While I'm a huge advocate for people knowing how SQL Server works, I'm also quite lazy and if a tool can make my job, my life, easier, I want it.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning