Differentiate Development & Production DB Connection

Recently I was using SqlEditor and was connected to multiple DBs sessions development DB and live production cloud DB at the same time. Since I could not differentiate the connection at a glance. I was about to run the script which had some hard code DEL & UPD statements meant to be run for development DB instead of production DB. Luckily I had reviewed the connection info and saved myself from committing the blunder.

I suggest to the SA team to add a simple checkbox indicator on the login screen "Production DB"; if the connection is "Production DB" then the SQL editor background should be some other light color but not the default color; this will at least help the developer to know if the DDL/DML/DQL/DCL is run on the production or dev DB and so to be careful.

This is simple to implement but a very useful and critical hint to the developer.

If possible implement this suggestion in the upcoming ver 12.x.

You can color your connections in the connection manager.

"Highlighting Color".

There is also a shortcut. You can double-click or right-click, on the server name in the status bar, and it will let you choose the color right there, and remember it.

Thanks! Since it was hidden inside the options button I was unaware of its existence.

But my suggestion to have an indicator "Production DB" (next to Auto-Connect checkbox) is a value addition if you seriously consider it. There are some additional validations that can be performed if the Indicator is maintained like the app can show a warning msg before executing "You are about to run delete/update/truncate/drop statement/script on production DB". Without an indicator, this is not possible.

Color plays an imp role but showing a warning is like a red alert in case if the user or another user is in place using the app and he/she is unaware of the color associated with production DB.

hitesh wrote:

Thanks! Since it was hidden inside the options button I was unaware of its existence.

But my suggestion to have an indicator "Production DB" (next to Auto-Connect checkbox) is a value addition if you seriously consider it. There are some additional validations that can be performed if the Indicator is maintained like the app can show a warning msg before executing "You are about to run delete/update/truncate/drop statement/script on production DB". Without an indicator, this is not possible.

Color plays an imp role but showing a warning is like a red alert in case if the user or another user is in place using the app and he/she is unaware of the color associated with production DB.

I imagine you could roll your own... make a procedure that takes your SQL string as input, checks for prod db and raises an error.. at least to avoid execution on prod without perhaps another optional input parameter to confirm you do indeed want to run on prod.

Or some sort of snippet in SQL Assistant to do the same

Mindflux wrote:

hitesh wrote:

Thanks! Since it was hidden inside the options button I was unaware of its existence.

But my suggestion to have an indicator "Production DB" (next to Auto-Connect checkbox) is a value addition if you seriously consider it. There are some additional validations that can be performed if the Indicator is maintained like the app can show a warning msg before executing "You are about to run delete/update/truncate/drop statement/script on production DB". Without an indicator, this is not possible.

Color plays an imp role but showing a warning is like a red alert in case if the user or another user is in place using the app and he/she is unaware of the color associated with production DB.

I imagine you could roll your own... make a procedure that takes your SQL string as input, checks for prod db and raises an error.. at least to avoid execution on prod without perhaps another optional input parameter to confirm you do indeed want to run on prod.

Or some sort of snippet in SQL Assistant to do the same

Doing it manually is not a viable solution. Consider this practical case.

Most developer(s) works on the development DB most of the time but often access production DB to address end-user issues. Now the production DB may be an in-house server(s) or a VPS cloud server hosted on multiple cloud providers. It is not practical to pass the connection string and validate things manually. If a simple indicator is available during connection setup then life will be easy; all I need is to tick the check box and SqlEditor will do the rest even if production DB is running on different servers or server parameters change in the future.