Toad World® Forums

bug 1 of 4 in "quick browse"


#1
  1. Pressing F3 does not open the window - you have to right click and select “quick browse” - instead it says “Search string ‘’ not found” with an OK button. - this is because F3 is also mapped to the “Find Next” under the Serach menu.

all regarding build 844
Message was edited by: kyle.brazell@verizonbusiness


#2

The quick browse of a partition uses * instead of the actual column names in the auto-generated SQL. The choice is also called “Brose Data” instead of “Quick Browse” - and it is missing the icon identifying icon in the context menu. Using the same code for all the similar operations means fewer code paths to execute in testing.

Message was edited by: kyle.brazell@verizonbusiness


#3

There is no “Quick Browse” option at all at the sub-partition level.


#4

OK, not so much in teh “Quick Browse” category, but that is what I was testing when I found it. In the two differnt tree views of the database schema, the tables are presented differently. In the tree-view attached to the tabbed editor panel, the partitioned tables appear as a sub-element in the main Table tree and the count of the partioned table is not added to the count of tables in the main tree. This presents two different ways to navigate the objects and means you have twice as much tree-view code floating around. At least make them look alike


#5

Hi Kyle,

F3 behaves as expected within a context.
If SQL Editor is active, then F3 behaves like “Find Next”.
If DB Nav Tree is active and you select table or view it opens “Quick Browse”.
If browser or splash screen is active, then it is F3 shortcut is disabled.

Rgds,
Andrew


#6

Andrew, perhaps Kyle is right about F3 - it didn’t work in earlier builds…

Roman


#7

Hi Kyle,

There are many ways that DB Navigator and DB Explorer trees are different. It would be impossible to make them the same, they’re different designs. Our purpose is to eventually make them do and look almost the same, but it’s in the future. We just want to know what particular solutions in the new design users will prefer to the old and vice versa. This will make our task easier.

Thank you,
Roman


#8

I do not have ready available build 844 to confirm your findings, but tested this on build 847 (see attachment), where it seems all raised issues are resolved, except "Select * ", but this, personally, I am not sure whether we should change. Maybe, Roman or Peter can add their opinion about this designe issue?

Andrew


#9

I’ll re-test it in the newer build then.

As for the context sensitiveness of F3, I guess that makes sense, though I might ask for a change so that the trees that serve a similar function behave more alike.

And on the “select *” - the most common use (for me) is to use the automatically generated SQL as the base for another more complex query and having the columns named is a huge time saver. So if you are taking votes for features. Count me please!

Most of these are “nits” and the overall function is great so don’t feel unappreciated!

Happy New Year!


#10

I agree - the most common use for quick browse for me as well is to cut/paste the resulting query somewhere else, or add to it.

Also, I can confirm that in 844, and with focus on a table name, pressing F3 still does a Find Next instead of a quick browse


#11

Thanks for comments. F3 issue in connection with Find Next is already fixed and will be in the next drop of Beta.