[DCrouse]

'peterlaursen' wrote on '17:

Problems are:

1) the (global or per-user) max-connections settings on the server may not allow too many connections

2) In particular with SSH-tunnelling it will be costly and sometimes slow too (reverse DNS lookup is involved).

There aren't really any added issues with this approach vs. requiring the user to go through the connection manager to open a new session (and displaying that session as a separate parent tab vs. a query tab under the parent.) Getting into implementation details here, but you could even have it “clean up” after itself – closing sessions after the statement is executed and opening them as needed. I don't think this is necessary though.

It's really just an improvement to the presentation of work spaces (in my opinion.)

[DCrouse]

Correct – I did notice that movement between connections is still enabled and I think that's the right idea, but as a user I'd like to see this taken a step further:

Instead of the parent (connection) tabs representing a single connection, they could each represent a group of sessions using the same connection parameters, and each of the child (query) tabs would manage their own database session behind the scenes. The user fires off a long running query/procedure from Tab 1 and decides to peek at some dictionary tables/metadata/etc – by simply opening a new query tab (no need to go through Connection Mgr) and the application creates an independent session for any statement run from it. And the other note I added is that the user should still be able to modify the statement or add statements to Tab 1 during execution.

It may be a technicality, but it is very useful to be able to move around unhindered like this. The interface is very well organized as it is, and I think adding some more function to it would be great.

[Author]

Posts