Like a lot of developers and database administrators, I do a fair amount of short-term problem solving during the course of my normal work week. I get to join some Redgate sales calls, often during Proof-of-Concept exercises, and this frequently involves helping brainstorm about the best way to use our tools to solve a specific need for monitoring, database development, or automation. I also pick up customer questions from the #Redgate channel in the SQL Server Community Slack and answer forum questions for Redgate when I can. Inevitably, when you do a regular amount of troubleshooting and brainstorming with customers, you start to notice patterns and have ideas about how to make things easier, faster, or better in some ways. Sometimes this is an idea for a new process or a new product, or it might be a big change to existing processes or products. The challenge is getting it…

Building your database code is an essential practice to ensure that it compiles from source and that dependencies are met. But things can get tricky when you have objects in some databases which is dependent upon objects in other databases — or even circular dependencies. In this 20 minute video, I give an overview of the two most popular options that Redgate customers use to manage cross-database dependencies when building SQL Server databases with Redgate’s SQL Change Automation.

I recent chatted with some folks who have a permissions problem in SQL Server. The permissions problem isn’t technical — it’s a process problem. The issue is that these folks are trying to configure a build for their SQL Server databases using Redgate tools, but they aren’t allowed sysadmin permissions on any SQL Server instance in their organization (even in development environments), because of a policy set by the Database Administrators in IT. Why do DBAs deny sysadmin permissions in development? You may find this type of policy puzzling — and for good reason. After all, if you don’t trust developers to keep their own development environment running, why would you ever trust any code they’ve written enough to deploy it to production? In that question is a bit of an answer: this policy occurs when there is a fundamental lack of trust between development and operations. The policy that…