kpi6288@xxxxxxxxx writes: > Thanks for the link but we're very reluctant to use Java based programs. > The main reason is that we need to do some works on servers whose admins simply do not allow to install Java. > The screenshots look very promises, however. > > Regards > Klaus > >> -----Ursprüngliche Nachricht----- >> Von: Thomas Kellerer <spam_eater@xxxxxxx> >> Gesendet: Montag, 25. März 2019 12:06 >> An: pgsql-general@xxxxxxxxxxxxxxxxxxxx >> Betreff: Re: Forks of pgadmin3? >> >> kpi6288@xxxxxxxxx schrieb am 22.03.2019 um 17:25: >> > 95% of my time I use pgadminIII just to type select and update >> > statements and review the output rows. >> > >> > I know that I can do this in psql but it’s not handy with many >> > columns. >> >> An alternative you might want to try is SQL Workbench/J: https://www.sql- >> workbench.eu/ >> >> Full disclosure: I am the author of that tool. >> >> It's a cross DBMS tool, but my primary focus is Postgres. >> >> It focuses on running SQL queries rather then being a DBA tool. >> >> Regards >> Thomas You may not need to install anything on the server. GUI based tools like dbeaver (also java) and I suspect this one, just run on your desktop/laptop. You connect to the remote DB as normal i.e. port 5432. If your network environment is locked down to only allow connections to port 5432 from specific servers and localhost (i.e. the server), then SSH can work. You use an SSH tunnel to tunnerl traffic for port 5432 to a local port and then configure the connection as a local connection using that port e.g. in one terminal ssh -L 3330:localhost:5432 db.server in local software tool, configure the connection with host localhost and port 3330. It may also be necessary to setup proxy connections if the host your allowed to connect to is not the db host, but many tools support this as well as it is a common restriction. You can also use ssh here, but it is a little more complicated, but same principals. BTW, the blanket restriction on java runtime is IMO misguided. There is nothing inherently more risky about the Java runtime than anything else (python, perl, ruby, node, etc). In fact, the JVM is a pretty decent bit of kit. The Java language is horrible to work with, but that is a different issue. There are some bloody awful Java applications out there, but this really means, assess on a per app basis, not a blanket ban on all of them. There are insecure and poorly written apps in every language. Tim -- Tim Cross
