Sql-server – How to minimize the risk of accidentally modifying the wrong database

sql serverssms

I just learned the hard way that disconnecting from a server in the Object Explorer doesn't stop you afterwards from executing query windows that were already open on that server.

My situation is like this: I have one instance of SSMS that I use to connect to our dev/staging server and to our production server. I had to delete a bunch of data on dev so I figured I should close my connection to production, but I didn't pay attention to the query window I was using. (Luckily we had a backup of only a few hours old.)

I'm not the first person to destroy production data and I won't be the last I'm sure. So
I'm looking for checklists, best practices, etc. that help you to minimise the risk of executing queries on the wrong database. Have you had this happen to you before, and how have you adapted your workflow to try to avoid this?

Best Answer

One thing I like to do in SSMS is to use Custom Colours when connecting to database. So you choose a nice bright Red for Live databases, and a gentle blue or green for dev or test systems. I used to use the inbuilt SSMS, but these days I prefer the SSMS Tools Addon Colour coding.

Like this

Or like this for SSMS Tools (A really nice addon, and I find the colour better when it's on top, rather than on the bottom like the built in on) Or this