Know which server you are on before you press F5

Everyone in this field has either done it or come within one keystroke of it: the editor tab that looked like the test system, an UPDATE without a WHERE, and a very quiet few seconds afterwards. The usual defences are a naming convention and paying attention, and both fail on the day you are tired.

Version 4.01 adds an Environment tab to the connection properties. It answers two separate questions: what kind of system is this, and may I write to it.

The four classifications

Each classification has its own colour, and that colour appears in the two places you are actually looking: the Server Navigator tree, and the tab of the SQL editor you are typing into. Next to the colour sits the badge — [DEV], [TEST], [PROD], [FAILOVER] — because a signal that only exists as a colour is not a signal for everyone, and does not survive a screenshot pasted into a ticket.

Why read-only is a separate switch

Because the two questions genuinely come apart. A shared test system that four teams rely on is a Test system you should not be writing to. A reporting replica is not production, but writing to it is meaningless at best. And a production system during an agreed maintenance window is a system you are deliberately writing to, where you still want the red marker shouting at you.

So: Connection is read-only sits next to the classification and is independent of it. Choosing Production or Failover ticks it for you, as the safe default; you can clear it again, and a confirmation asks first in either direction — turning the guard off is a decision, and so is turning it on for a connection someone else may be using.

What the guard actually refuses

• The SQL editor passes only statements it can recognise as read-only. A statement that writes does not leave the client.
• The result grid stays uneditable — no in-place cell edits on a guarded connection.
• The Data Pumper refuses it as a copy target.
• The class actions — Delete, Copy, Import, Compile — and the cached-query purge refuse to run against it.

After the update, and where it comes from

Connections you already have keep their protection. One that was already classified as Production or Failover is read-only after the update without any action from you; nothing else is silently locked down.

For IRIS and Caché the classification can follow the instance's own system mode, so a server the administrator already marked as a production instance arrives here classified — without a second, hand-maintained list of which server is which. Taking that value over never switches the read-only guard off.

One classification is set for you and cannot be argued with: the SQL analytics endpoint of a Microsoft Fabric Lakehouse is read-only because the endpoint itself is. See Azure SQL and Fabric.

Rolling it out to a team

A classification is only worth something if everyone's client agrees on it. Export the connection — or the whole group — as a team profile, put the file on a share, and everyone who imports it gets the same servers with the same classifications and the same guards, and no credentials in the file at all. That mechanism is described on secure connections.

Next step

Classify your production connection first, before anything else. It takes about fifteen seconds and it is the one that matters. Download SQL DATA LENS and start there.