How can we help you today?
DbVisualizer 5.1.1.5 is now available
35 CommentsSorted by Oldest First
Roger Bjärevall
said
almost 17 years ago
[This reply is migrated from our old forums.]
Re: DbVisualizer 5.1.1.5 is now available
Re: DbVisualizer 5.1.1.5 is now available
Ronald,
Does the copy key binding work better in 5.1.1.6?
Regards
Roger
[This reply is migrated from our old forums. The original author name has been removed]
Re: DbVisualizer 5.1.1.5 is now available
Re: DbVisualizer 5.1.1.5 is now available
Roger,
It does work for the data grid in the object view, not from the result grid in the sqlcommander.
regards,
R.
It does work for the data grid in the object view, not from the result grid in the sqlcommander.
regards,
R.
Roger Bjärevall
said
almost 17 years ago
[This reply is migrated from our old forums.]
Re: DbVisualizer 5.1.1.5 is now available
Re: DbVisualizer 5.1.1.5 is now available
Ronald,
Ok, got it.
Copy via key binding seem to work fine if the result set grid is edit enabled while it doesn't for read-only result sets.
I'll look into it.
Thanks!
Regards
Roger
[This reply is migrated from our old forums. The original author name has been removed]
Re: DbVisualizer 5.1.1.5 is now available
Re: DbVisualizer 5.1.1.5 is now available
Roger,
I continued testing with 5.1.1.6, now that the live-saving Stop button is back.
Having used the new quick and where filter dialog quite a few times now during daily work I can see the value in making these persistent (although I never even got near using the sort section, this feature apparently does not fit into my usage pattern).
I am working in manufacturing and many times a day I click the Data tab and enter something like:
facility = 'Foo' and lotid in ('first_id','second_id','third_id')
for various tables. These where conditions are almost all one-time shots that do not need to be remembered (would even be considered as noise). Usually the list of lot ids is edited several times before moving on to the next task.
For this scenario the new filter handling is a real pain, in particular, closing the dialog after clicking "Use filter".
Regards,
Georg
Roger Bjärevall
said
almost 17 years ago
[This reply is migrated from our old forums.]
Re: DbVisualizer 5.1.1.5 is now available
Re: DbVisualizer 5.1.1.5 is now available
Georg,
Thanks for your observations.
You mention that you need to close the dialog after pressing "Use Filter"? Pressing "Use Filter" should apply the filter and close the dialog in one step.
We will consider a change/enhancement of the filtering feature in general to satisfy users that like the old style.
Related to this: would a solution with a text field that supports auto completion of column names be an option i.e. the text area showing the complete filter in the previous version? The idea is to offer a text area that is used to browse and optionally edit the filter. This can be used by advanced users to do quick edits of the filter but still keep the UI less cluttered from buttons and fields.
Regards
Roger
Roger Bjärevall
said
almost 17 years ago
[This reply is migrated from our old forums.]
Re: DbVisualizer 5.1.1.5 is now available
Re: DbVisualizer 5.1.1.5 is now available
Georg,
Sorry I missed to answer your query about error location in Oracle statements.
> I know this is OT with respect to this thread, but
> are there any plans to make the editor tell the user
> where the errors occurred in an SQL statement (I
> thought it might not be possible because of
> limitations in the (Oracle in my case) JDBC
> implementation, but I had a look at Oracle's SQL
> Developer and it does this even when using the type 4
> driver) ? Nobody would be shocked about this :-)
We haven't reviewed the latest versions from Oracle lately so I cannot comment whether this has been improved. I am not surprised the Oracle tools have this and have had for a while, after all they know about all their inner secrets :-)
Seriously, if their tools are using the standard type 4 driver then it is a bit surprising as there are no public API that can be used to get information such as error location, etc.
We'll look into this again.
Regards
Roger
Roger Bjärevall