Open two connections and close the editor on the second connection.
The first connection becomes active and its editor is displayed.
I can now switch back to the second connection, but the editor of the first connection is still displayed.
So now the Connection Bar indicates that the second connection is active, while scripts will be executed with the first connection.
There is some room for improvement here, I’ll take a look.
Usually when an MDI child window (the Editor, Schema Browser, etc.) becomes active it changes the active connection to its connection. This is evident when both of your connections have Editors and you activate each of the Editors. In this case with only one Editor it is active, never loses its active state, thus never re-activates to set your first connection as the active.
In the meantime you have a couple of options.
Pay attention 
Use connection colors. This should help visually and may be your best short term bet.
Enable the “Show Buttons for Current Connection” option available via rt-click on the window toolbar. This just makes it clearer that the Editor is not for the active because it won’t have a button on the toolbar.
Michael
I have given this some thought and investigation and I don’t think there’s much to do about the danger aspect. It seems that there is both a bug and a caveat here. Using your connection 1 and 2 example where connection 1 has Editor and connection 2 is active…
Bug: When you interact with the Editor whether it be clicking within, typing, or executing some action using shortcut the connection bar for connection 1 does not toggle to indicate that it is active.
Caveat: What you see as the active window does not match what you see as the active session. This is just how it is and has always been. Connection colors would help here as long as you use different for connections 1 and 2.
I have the bug fixed for next beta so that the active session indicator is correct. This makes it more obvious if your first interaction with the Editor is by clicking within or text insertion. If you go straight for a shortcut or click on an Editor tool button you’ll notice nothing until the moment you release the key/button.
Michael
The easiest way for me to avoid this is not to close the last editor.
I don’t think that this will ever happen to me again, just wanted to share it with you to avoid some critical problems that can happen when one thinks they are connected to a different database than they actually are. Your suggested solution should improve the situation, but as you said there still is an option to mess up.
Solutions that come to my mind that would avoid the problem altogether:
This behavior goes back a very long time, probably even to the first Toad ever made or at least the first time Toad was an MDI application supporting multiple sessions. Both of those solutions would work, but would be quite a disruption for others. I don’t doubt that this may have been a critical issue for some at a time or two.
Michael
[quote]Since a new connection always comes with an Editor,[/quote]Doesn’t that depend on what you have ticked for Auto Open in Toad Options, Windows?
Best regards,
Niels
@Niels: You’re right, thanks for pointing this out! I haven’t even been aware of this setting.
@Michael: Thanks for explaining. I still think that displaying childs of a different connection is a bug, but it should not affect me.
Curious to see your bugfix. If I got it right, then you would allow me to execute a fatal script for a connection that is not active (using a button), but pretend that it was active afterwards 
If I got it right, then you would allow me to execute a fatal script for a connection that is not active (using a button), but pretend that it was active afterwards
No. Once you click in the editor and click the execute script button the session is active. No pretending there. In one fell swoop you are activating the session and executing.
Michael
Peter, I had to rollback the change for this behavior. A more severe bug resulting from the fix was discovered.
Michael
