Q: How can I diagnose and correct problems with the Query tool connection.
Using pgAdmin4 1.0-rc1 to connect to a local host "PostgreSQL 9.5.3, compiled by Visual C++ build 18..."
I can connect and drill down to my schema. I use the context menu to select 'Query tool'. The editor shows the correct database#host:port in the editor header bar.
When I execute a simple query, or any query
select 1 as first;
I get the message
"Not conencted to the server or the connection to the server has been closed.
instead of the expected results.
The editor alwa
This issue has been resolved now,
Upgrade pgAdmin4 to version 1.3. https://www.pgadmin.org/download/
All you have to do is wrap the schema, table, column names with double quotation marks in every sentence.
Related
I have this client where we installed a PGSQL server on his server (PGSQL 13 on port 5432)
There already was a postgresql server installed (8.3, port 15432).
No problems here.
Our application has a few 'bytea' columns where we store some encrypted data. Strange things happen when I launch a SQL on this column.
Exactly the same code gives different results on different computer.
For example: "Select ByteAColumn from RandomTable"
Results on my computer:
"E712F7671E929600C926003C61C4C696C27E89C8D836F85898737799DFAB1CC4"
Result on server where the Postgresql is installed:
"\x45373132463736373145393239363030433932363030334336314334433639364332374538394338443833364638353839383733373739394446414231434334"
Result on other computer in the network of the client:
"E712F7671E929600C926003C61C4C696C27E89C8D836F85898737799DFAB1CC4"
Result on "Select ByteAColumn::varchar from RandomTable" in PGAdmin 4:
\x45373132463736373145393239363030433932363030334336314334433639364332374538394338443833364638353839383733373739394446414231434334
My application expects the "E712F7671E929600C926003C61C4C696C27E89C8D836F85898737799DFAB1CC4" one and throws error on the result with '\x4...'.
I can avoid this using "Select encode(ByteAColumn,'escape') from RandomTable", this gives the right results. Modifying our entire application is near impossible.
In other words: the application runs fine on my computer, works fine on client computers / terminal server but not on the server where the postgreSQL database is hosted.
I've been using this application for over a year now. I have done many installations of this application and never have had this issue before. I've tested the query on other installations where everything is fine, and there I also get the '\x45...' result, but using the query in my application works great.
What causes this?
Is it the PostgreSQL 8.3 server which interferes somehow? I've been testing and searching a whole day now and I can't seem to find the answer.
Help would be greatly appreciated.
Thanks!
Running any sort of query on pgAdmin 4 just returns a 'table_oid' under messages.
I am able to get the necessary data when running the query from the command line, for example
SELECT ST_MakePolygon(ST_GeomFromText('LINESTRING(75.15 29.53,77 29,77.6 29.5, 75.15 29.53)'));
I understand that table_oid refers to the object id of the table, but I have no idea how to access it.
Pardon me please if it is a simple question, but I am unable to find any resources online
Expected:
010300000001000000040000009A99999999C9524048E17A14AE873D4000000000004053400000000000003D4066666666666653400000000000803D409A99999999C9524048E17A14AE873D40
Actual:
table_oid
From pgAdmin 4 project tracker:
Temporary solution until next release and tested in my ubuntu 18.04 machine:
Replace these two 2 files:
/usr/share/pgadmin4/web/pgadmin/tools/sqleditor/__init_*_py
/usr/share/pgadmin4/web/pgadmin/tools/sqleditor/command.py
Link to files:
__init_*_.py
command.py
Note:
The first file's name is __init_*_py, without the *.
Try Squirrel SQL - Universal SQL Client. It's an extremely useful SQL client. I use it to access SQL Server, PostgreSQL, MySQL, Access. It's not as good looking as pgAdmin4.
Install JAVA first, if not already installed.
Install Squirrel SQL.
Download the latest PostgreSQL JDBC driver, e.g. postgresql-42.2.6.jar, and put it into a convenient location.
Open/Start Squirrel.
Click the Drivers Tab and scroll down to PostgreSQL. Double click PostgreSQL. A "Change Driver: PostgreSQL" dialog box/window will open.
Click the Extra Class Path tab and click the Add button. Navigate to and choose the PostgreSQL JDBC Driver that was downloaded in step 3. above.
Click the List Drivers button, "org.postgresql.Driver" should appear in the Class Name drop down box.
Click OK.
Setup PostgreSQL JDBC Driver
The driver should now be setup.
Click the Aliases tab to setup a connection to your database. See my example screenshots.
Setup Database Connection
I connected to remote PostgreSQL database using IntelliJ IDEA 2017.2.1 successfully and executed some select queries on one of the tables. I got the results. I wanted to dump the results data to a file or the clipboard, but the 'Dump Data' command is disabled. Any idea why that might be or how to tell the reason? Thanks.
It does not matter which output format I choose from the Select on the left of the Dump Data button. I have updated the DB driver to the latest version.
I am using:
IntelliJ IDEA 2017.2.1
Build #IU-172.3544.35, built on July 31, 2017
Mac OS X 10.12.6
The Dump Data To File/Clipboard action becomes disabled for those query results (and corresponding SQL Console) for which database parameters (like current database/schema or search path for Postgres/Redshift) have been changed after you got those query results.
I.e. when you execute select query using one current schema (search path in Postgres/Redshift) and then change the schema (i.e. with the 'use' statement) to another schema(search path in Postgres/Redshift).
And it should get enabled after you re-run the query with the changed parameters or revert them back.
Repeating query as suggested did not help. Nor did a regular restart. Invalidate Caches and Restart did the trick.
I am using intellij with postgres, and highlight sql commands to run them.
I also have postgres running in my terminal, and I am getting different results from the same query when run in intellij vs. when run in the terminal.
Here is the command run from Intellij:
The result shows one entry present:
However, running the same command in the terminal shows no table entries present.
Intellij and the terminal are connecting to the same database and port as shown by Intellij's connection settings
and by the result of \conninfo run in the terminal.
Furthermore, the schema matches as shown by Intellij's connection settings (shown above) and by the result of the terminal's \d+ visitor_sign_in command
Why does this same command give different results when run in Intellij vs. when run in the terminal?
Based on your most recent comment ("yes running select * from pg_stat_activity; does show 'idle in transaction'."), here is what I believe is happening.
You have two connections, A and B.
A starts a transaction, inserts data, and then selects from that table. The table shows data (the data that was just inserted).
B connects, and selects from the same table. Since A has not committed, B does not see that data. In order for the data inserted by A to be visible to any other connections, you need A to commit its transaction.
Now, I don't know why IntelliJ is not offering you the opportunity to commit your transaction, but that lack of commit is the cause of your visibility problem.
I'm using Eclipse Juno with the SQL Explorer plugin. I've set up an SSH tunnel for port 3306 via Putty to my production server and have successfully connected to that server's MySql instance. I can view the database's schema as well as getting a preview of a table's data. When I try to execute a basic SELECT query, without a database qualifier on the table, Eclipse gives me a NullPointerException with no additional information. However, if I include the database qualifier, it works.
The database selector in Eclipse/SQL Explorer is set correctly and everything works as expected if I'm not running over the SSH tunnel (e.g. locally or a direct remote connection).
Is there something that I'm overlooking?
The problem was caused by a bug in the SQL Explorer plugin (see http://sourceforge.net/p/eclipsesql/discussion/450662/thread/f1e73461). The symptom was a red herring. The NPE would occur when the plugin tried to write to its history file. Clearing the history file resolved the problem.