Start a new topic
Solved

Postgresql Db Connections in 95

[This topic is migrated from our old forums. The original author name has been removed]

Hello! I am really happy to see evolving Postgreql support in Dbvis! Some first thougths using version 95.2524. Owerall the design seems reasonable and is much like the setup familiar from pgAdmin III, and works well. The browse tree depth to database objects will remain the same. In the case that your cluster (in the Postgres meaning) has lots of databases, you should be able to filter the databases shown. At the moment filtering on the database level is not possible at all "Object type cannot be filtered". What I would really like to have is the possibility to set some preferences per database, e.g. search_path or role. This could be an on connect executable statement. Also, the 'permission mode' will also now be common for all databases. A nice little feature to the connection wizard would be to offer 'postgres' as the database to connect to. (The default when a database is not specified is the same as the user name which does not necessarily exist). The AppicationName parameter could also be set to some reconizable string. Cheers, Jonas

[This reply is migrated from our old forums.]

Re: Postgresql Db Connections in 95
Hi Jonas, Glad to hear you like the improvements! You can filter which databases to show. It sounds like you selected the Databases node, which is a grouping node and it cannot be filtered. Instead you need to select the Catalog child node. This is the same as with other object types, e.g. Tables and Table nodes; only the latter can have a filter. Great to get your feedback on things that may need to be set at the individual database level. Looking at pgAdmin III I see that you can bring up the Properties dialog for an individual database, but everything seems to be read-only. Can you set search_path and role in pgAdmin III and if so, how? It would be good to know as background. Regarding your suggestion, would this scenario work: 1) Expand the connection node to connect to the server, 2) Expand the Databases node to see the individual databases, 3) Double-click the database node to open a Properties tab with content similar to the Properties tab for the connection, 4) Make any changes that should apply to the individual database. The Properties tab would most likely not have the Database Profile node, and just some of the other nodes. This means "set search_path" and "set role" statements could be added as Connection Hooks and Permission Mode could be set as it is done at the connection level. The above can be kind of tricky to implement, so I would really appreciate your feedback on the most important properties that need to be adjustable at the database level. At first glance, it looks like only the Driver Properties, PostgreSQL (the grouping node with Permission Mode), and Connection Hooks should be included in the database-level Properties tab. Permission Mode could be possible to set at database level, but I can think of a few issues with getting the corresponding border/color rendered for its tabs until there actually is a physical connection established for the database. Making the Database field default to 'postgres' is very easy. In fact, I have already fixed so it will be the default in the next Beta. The ApplicationName is a driver property, so if we do the above it can be set at the database level, but it is not all that easy to give it a default value that is different than what the driver use as a default. I appreciate your help with making sure we get the PostgreSQL support right! Best Regards, Hans

 Hello!


Good to know that the filtering is there, the UI for defining the filters can be somehow challenging to get right sometimes. Looking at the tree again, is the level "Schemas" needed at all?


For the per-database settings - actually they can not be set in pgAdminIII - which is one reason to use Dbvisualzer.


The place for setting per-database settings seems reasonable. The settings suggested seems ok, I would also add the Transaction settings.


Hope that you sort it out, but I would say that it is not a show-stopper, since you can always make another connection and tune it to your needs.


Nice to see that the default postgres database setting is there.


For the ApplicationName property, by default it is empty, and it should identify the application, at the connection level, there is no need to set it on the database leve. It could be whatever you want to announce Dbvis as against the database, by default.


One note, if you can't connect to a database, there will be no feedback on that and no visual hint that a connection attempt failed.


Still thinking on a situation with lots of databases in a cluster(perhaps hundreds), could it be convevient to add an option to the connection wizard to switch on the 'show only the database filter option'?


Cheers,


Jonas



Hi Jonas,


The filtering tree (just as the tree in the Databases tab) has grouping nodes with plural names (Databases, Schemas, Tables, etc) and object nodes (Catalog, Schema, Table etc). Filters can only be defined for the object nodes. I assume that you ask if the grouping nodes are really necessary?


We discussed per-database setting yesterday and came to the conclusion that it would be a major change with lots of risk, so we will not do it for the initial 9.5 release and would like to see requests for this from others before we consider it. As you say, the same thing can be accomplished by creating separate connections for the databases that need tuning.


I have opened a ticket for looking into setting the ApplicationName driver property to a default value.


I will look into the issue with the lack of feedback when a connection cannot be made to an individual database. I assume the typical example would be that the account has no connect privilege?


I have opened a ticket for adding a Show Only Default Database/Schema option to the Connection Wizard.


Thanks for all your feedback!


Best Regards,

Hans

Hi,


On the grouping nodes - I am not asking to take avay the grouping nodes. I am just concerned of the tree depth to actual database objects. Since now both multiple databases on one connection and Postgres uses schemas, the tree will be deeper than eg for Oracle (one database per connection) or mysql (no schemas in database). But a flexible database, gives lots of variations!


For the database connection issue, yes, it is precisely the lack of CONNECTION privilege that denies a user access. The SQL commander will show an "Error Alert" dialog when changing the database in the dropdown menu but not when opening a new SQL commander with the database selected it the browser tree. Could the same overlay as for the connection be used as a visual feedback?


As for the per-database settings, I fully understand that it need some more thoughts to be successful and usable.


Cheers,


Jonas








Hi Jonas,


We've just released DbVisualizer 95.2558 BETA which includes a fix for the problem establishing connections for a database node. Easiest to upgrade is to open Help->Check for Update in DbVisualizer.


Regards


Roger

 Hi Roger,


thanks for the update! I tested it and I would like to still comment on these, if I may.


Now that that the situation when a connection to another database within the same connection gives a quite verbose feedback - the name, colour of the name and comment on the node is changed. This will stay visible in the database listing, with no possibility to hide it, like e.g. when trying to acess Foreign Servers for a non-superuser.


On the other hand a connection failure just add a failure icon overlay and presents the rest of the information in a hover, which i think is nice.


In the sql commander, there is no visual indications that the database is unnaccessible, as there is for the connection, and after dismissing the first error dialog, there no feedback at all if trying to execute a query on that database. The database node in the browse tree is not necessarily visible at all times, which shows the status.



Cheers,


Jonas

Hi Jonas,


Ah my bad regarding the Database list in the SQL Commander. It should of course adjust to what databases are really available. I'll open a ticket on this.


Do I understand you correct that the current reporting for database connections that cannot be established in the Databases tab is good enough?


Regards


Roger

Hi Roger,

The database connection failure reporting is good enough, yes. And with adjusting the commader database selection, the solution seems owerall working.

Cheers,

Jonas

 

Hi Jonas,


I just wanted to let you know that we have released DbVisualizer 9.5 yesterday with a fix for the issue you reported. Easiest way to upgrade is that you open Help->Check for Update in DbVisualizer to perform the upgrade.


An alternative is that you download from our web site: 


http://www.dbvis.com/download/


Best Regards,

Hans

Hi Jonas,


Just to inform you that we've released DbVisualizer 10.0. It now shows "dbvis" as the application name in PostgreSQL.


Use Help->Check for Update in DbVisualizer to install the new version or visit the download page on our web. The Check for Update will also indicate whether 10.0 is a free upgrade.


Regards


Roger

Login or Signup to post a comment