Link Query Tabs To Schema Drop-down

[gb1071nx]

Apologies for bringing up the competition, but if you're familiar with it, you'll understand pretty quickly.

In DBManager Pro (www.dbtools.com.br) I'm able to open multiple query tabs, and in this program, the “schema drop-down” stays connected to each tab. So if on one server, I have 'database1' and 'database2', I can open one tab and set it to 'database1' and open a second tab and open it to 'database2', and they *stay* that way. I can switch between the two tabs, and thus, the two schemas.

in SQLyog, the schema drop-down seems to not be connected to each tab, but is a global setting for all tabs.

As a user of DBManager, who is contemplating a switch, this could lead to fairly disasterous results (at least for a couple times, until I relearn pretty d*** quick). Imagine that I'm in SQLyog on the first Query tab. I then open a second tab, change the schema, do a query, and based on that result, I want to now go back to my first schema and perform an UPDATE or DELETE. Except, now I've forgotten that having switched the schema for 'tab 2', I've switched it for tab 1 as well. I'm updating the wrong database.

Or less damaging (maybe.. depends on audience) , I have a number of tabs open and someone asks me “how many orders from customer A are there?” and thinking I'm on customer A's tab, I just “SELECT COUNT(*) FROM Orders” except I'm on the wrong schema.

Is there a possiblity to have functionality similar to DBManager within SQLyog? I understand that most current SQLyog users expect the current behaviour, and be put off by schema selection that 'sticks' to tabs like this, so my suggestion is to make this a user configuration (schema selection per tab – yes/no), with no being the default, and both sets of users “win”.

[peterlaursen]

I replied in your other topic!

What some other program does does not matter if it is wrong!

A query in MySQL (and therefore not a query tab either) is not restricted to access a single database!

I think instead we should 'push' the request (by other users and me!) to rename a Query Tab. It could be an option that the query tab gets named from the selected database at the time of creation (like 'query.1stdatabase.1','query.1stdatabase.2','query.1stdatabase.3','query.2nddatabase.1' etc)

If 'linking' means restricting access to other databases we won't!

[gb1071nx]

Yes, my other topic *looks* the same, but isn't quite.

On this one then:

DBManager doesn't “restrict” in the sense that if you typed “SELECT * FROM schema.tablename” into a tab that was currently on some schema != to the one specified in the SELECT.. it will still work as expected. You can do cross-schema SELECTs and all that, or a simple select from one schema, which happens to be different from your currently selected schema in the drop-down…

But what it *does* allow you to do (which IMO is not 'wrong') is select the (if you will) “default” schema for that tab, and then simply type “SELECT * FROM tablename”. And it allows you to set a different default for different tabs.

Do you feel that's “Crazy” and “wrong” ?

[peterlaursen]

no .. not wrong. There are always PROs and CONs with any GUI design.

In terms of SQL implementation we would then have to send a USE statement when a specific Query tab is clicked. That could be done, and we could relatively easy implement some kind of a 'properties' dialogue for a Query tab.

We should then optimally as well change the display of the selected database in

* the dropdown where selected database displays

* the Object Browser

when a Query tab is clicked.

If you noticed: when you select in OB the dropdown changes, but when you select in dropdown OB display does not (it is the dropdown that 'counts')! There are some coding difficulties here that have not been solved. If a Query tab should SIGNAL change-of-database to the other GUI elements then it get even more complicated. But of course complications is no excuse!

I think we will need to discuss this! We will relase 6.1 beta 1 shortly and after that we can get some air for discussing new ideas.

[gb1071nx]

peterlaursen wrote on Sep 25 2007, 02:50 PM:

no .. not wrong. There are always PROs and CONs with any GUI design.

In terms of SQL implementation we would then have to send a USE statement when a specific Query tab is clicked. That could be done, and we could relatively easy implement some kind of a 'properties' dialogue for a Query tab.

For what it's worth, using Wireshark, I see that DBManager issues something like that (I don't see “USE”, but I see the schema name) only when a query is run, not on a tab change. But that's an implementation detail.

peterlaursen wrote on Sep 25 2007, 02:50 PM:

We should then optimally as well change the display of the selected database in

* the dropdown where selected database displays

* the Object Browser

when a Query tab is clicked.

It should *definitely* change the drop-down. In prior versions of DBManager, this didn't always happen, and it was a bad, bad bug. You were never sure what schema you were really on. Object browser: I'd speculate it's not as important, IFF the drop-down is guaranteed to be 'correct' and to 'win'. The object browser is then just a way to navigate to, and open, new Query tabs ( and/or Data tabs; see my other post), but it doesn't have to frantically scroll and re-highlight to “keep up” with you flipping between tabs. I'd almost count that as a distraction.

peterlaursen wrote on Sep 25 2007, 02:50 PM:

If you noticed: when you select in OB the dropdown changes, but when you select in dropdown OB display does not (it is the dropdown that 'counts')! There are some coding difficulties here that have not been solved. If a Query tab should SIGNAL change-of-database to the other GUI elements then it get even more complicated. But of course complications is no excuse!

I think we will need to discuss this! We will relase 6.1 beta 1 shortly and after that we can get some air for discussing new ideas.

Thanks again for your thoughts on this. And apologies to repeated references to “the other guys”. 🙂

[Author]

Posts