Right now, typing a name from the Connection tab jumps to the first matching entry below the current cursor position. This is close to what I need, but I would like DbVis to search for a match anywhere within the current connection tree, only. Additionally, I would like it to assume a leading asterisk so it matches anywhere within the object name even if I forget to start with a "*".
I want to be able to type "PAR" and immediately position to W_SR_PARTY.
Because I have Dev, Test and Prod tables all with the same name, when the desired match in the same connection happens to be above where I am currently positioned, often times I will be taken to that table in a different connection. Therefore, before I move to another table I have to figure out which one is alphabetically first, and move my cursor above the target table before I start typing the name.
These problems would all go away if the search were limited to just the currently-pointed-to connection. Perhaps this could be a setting:
When I type a string in the Connection list:
__ Search entire connection list from current point on
__ Search anywhere in current connection
__ Match from the beginning of the object name
__ Match anywhere in the object name
Thanks. Got it now.
I'm sorry I communicated that poorly. I was not asking that the search be changed to search through connections that had not yet been opened. I think the way it searches right now is perfect the way it is.
Instead I am saying you should limit the search (not expand it) so it only searches within the current connection, rather than searching through all open connections. In other words, I can usually move the cursor to my desired connection, but once it's there, I want to find a particular name within that connection (like a schema or a table).
Also, if I happen to be positioned at a table alphabetically past the one I'm looking for, I'd like the search to wrap around to the top of that connection, without moving to a different connection.
Thanks for your post.
Currently the search feature only searches objects that has been expanded. Reason for this is that the objects list in the Databases tab is not fully loaded unless first expanding each of the nodes. Having a search feature that will search all objects, even those that hasn't been queried yet, would implicitly expand every node in the tree resulting in a query, and then match the names. Based on the current design this will require a lot of DB calls in order to fetch the data and performance will suffer i.e. the search will be dead slow. You can see this in the Search tab for a database connection which is basically doing what I am referring to above.
We do have an open ticket to look into caching of the database objects between sessions to solve this and other issues. However, that would require some level of redesign that we haven't looked into yet.
However, the match requests should probably be easy to fix... I'll open a ticket.