I get the following error when trying to connect to postgres as a target using AWS SCT:
LOADER ERROR: Error executing 'load-contexts' query: org.postgresql.util.PSQLException: ERROR: relation "aws_oracle_context.context" does not exist'
It appears to occur on the LOADER step load-contexts
All steps for LOADER until that point executed successfully per the log file.
Why would it be looking for a relation that appears to be related to oracle?
Referenced relation triggering error: aws_oracle_context.context
Postgres RDS version: 13.4
AWS SCT version: 1.0.660
Postgres JDBC Driver: 42.3.3 and 42.2.19
Any ideas / insight would be appreciated!
It appears the fix is to un-check Server Level Objects completely for the PostgreSQL connection you create under the Servers drop-dwon on the right hand side of the SCT interface.
It's selected by default when you connect so the tool will always fail on that job step for PostgreSQL it seems. Other aspects of the tool seem to work fine.
If anyone has anymore insight into this, feel free to share!
Related
I'm using the open source Metabase version, and I was able to connect my PostgreSQL databases correctly.
but when im trying to run a update query from metabase its throws below error.
ERROR: cannot execute UPDATE in a read-only transaction
but when I execute same query from terminal and pgAdmin its worked and updated the rows as well.
so i thought the issue is the connection between metabase and PostgreSQL,
then i tried to change the connection propertes as below way.
I have tried below arguments as well.
default_transaction_read_only=off
readonlymode=ignore
readonlymode=off
but im still geting the same error message.
Metabase isn't geared toward modifying any data in the source databases it knows about.
Seemingly as a way to enforce this usage pattern, Metabase's developers are using the setReadOnly method when creating JDBC connection objects which is likely overriding any driver-level properties you've set. (This happens in the file src/metabase/driver/sql_jdbc/execute.clj in the Metabase codebase.) You could attempt to change this by compiling your own custom version of Metabase, but you might achieve some unexpected results.
I need to implement migration tool like Flyway in order to use Jenkins to deploy DB changes.
I tried to add jt400.jar file and added configuration as follows:
flyway.url=jdbc:as400://192.168.171.251:446/DBDEV
flyway.driver=com.ibm.as400.access.AS400JDBCDriver
as a driver and it would not connect with this message:
ERROR: No database found to handle jdbc:as400://192.168.171.251:446/DBDEV
I also tried with using IBM DB2 driver and had configuration
flyway.url=jdbc:db2://192.168.171.251:50000/DBDEV
flyway.driver=com.ibm.db2.jcc.DB2Driver
this time I am getting this kind of refusal message
ERROR:
Unable to obtain connection from database (jdbc:db2://192.168.171.251:50000/DBDEV) for user 'DEVUSER':
[jcc][t4][2043][11550][4.26.14] Exception java.net.ConnectException: Error opening socket to server
/192.168.171.251 on port 50,000 with message: Connection refused (Connection refused).
ERRORCODE=-4499, SQLSTATE=08001
With this test migration I am trying to create a simple table by executing this sql
CREATE TABLE PERSON (
ID INT NOT NULL,
NAME VARCHAR(100) NOT NULL
);
Anyone had this situation and solved it?
I believe that at present there is no support for flyway to work with IBM i (as/400) regardless of whether you use jt400.jar or an IBM jdbc driver.
You can either use a different database-schema versioning tool, or find a fork of flyway that supports i-series (or pay someone to create and support such a fork, it is open source...).
It seems that currently (flyway 7.7.2) does not recognize a URL that starts with "jdbc:as400:" as a Db2 URL, so it throws an exception, which is the reason that the jt400.jar style URL is rejected with exception:
"No database found to handle ..."
The github history tells a story (see: https://github.com/flyway/flyway/issues/105).
Looks like the devs did not succeed to get the AS400 support added due to the lack of a suitable available i-series testing/dev environment (and also available to travis ci) . There may have been at least one PR for such support in the past, although it seems to be removed.
If you try to use the IBM db2jcc4.jar driver to connect to i-series (as400) with a url similar to: jdbc:db2://hostname/dbname, and you explicitly use an IBM jre , and have the relevant license file (e.g. db2jcc_license_cisuz.jar on the CLASSPATH), then flyway will connect and then report the exception similar to:
Unsupported Database: AS 7.4
The flyway source code shows that flyway does not recognize this database product-name and version, at current flyway version 7.7.2.
Are you sure DBDEV is the name of your Db2 data base on the IBM i?
Use the Work with RDB Directory Entry (WRKRDBDIRE) from the green screen, and look for the *LOCAL entry.
Or use the Access Client Solutions (ACS) "Schemas" tool to see a list of DB on your system.
The above shows 2 DB's, UT29p63 and Dbtest
I connected to my Heroku PostgreSQL database with Jetbrains Datagrip. Authentication was successful, I didn't need to specify advantage properties when connecting, when I filled host, db, username and password, Test connection was successful.
When I write query to console, everything works, for example:
SELECT * FROM users
find all users in my database.
I have problem, when I want to see tables in my database structure. They don't appear. In project tree, I can see only Database_name -> schemas -> public -> key_id_seq (image: Project tree structure). When I click on synchronize button, I get an error:
[42703] org.postgresql.util.PSQLException: ERROR: column t.relhasoids does not exist
Position: .
Error encountered when performing Introspect database *db_name* schema public (details): ERROR: column t.relhasoids does not exist
Position: .
ERROR: column t.relhasoids does not exist
Position:
Am I doing something wrong? Thank you.
Datagrip updated to version DataGrip 2019.3.3, Build #DB-193.6494.42, built on February 12, 2020, Now working :)
Try using "Introspect using JDBC metadata". This fixed it for me when (I think) I had a version mismatch between postgresql server and DataGrip client.
Under your connection settings -> Options tab -> check Introspect using JDBC metadata
According to https://www.jetbrains.com/help/datagrip/data-sources-and-drivers-dialog.html#optionsTab :
Switch to the JDBC-based introspector.
To retrieve information about database objects (DB metadata), DataGrip
uses the following introspectors:
A native introspector (might be unavailable for certain DBMS). The
native introspector uses DBMS-specific tables and views as a source of
metadata. It can retrieve DBMS-specific details and produce a more
precise picture of database objects.
A JDBC-based introspector (available for all the DBMS). The JDBC-based
introspector uses the metadata provided by the JDBC driver. It can
retrieve only standard information about database objects and their
properties.
Consider using the JDBC-based intorspector when the native
introspector fails or is not available.
The native introspector can fail, when your database server version is
older than the minimum version supported by DataGrip.
You can try to switch to the JDBC-based introspector to fix problems
with retrieving the database structure information from your database.
For example, when the schemas that exist in your database or database
objects below the schema level are not shown in the Database tool
window.
My case was different here. But I was getting the similar error:
An error has occurred:
01:15:21 PM: Error: ERROR: column rel.relhasoids does not exist
LINE 1: ...t_userbyid(rel.relowner) AS relowner, rel.relacl, rel.relhas...
I was using pgadmin 3 to connect to Heroku hosted Postgresql. Then I configure pgadmin 4. The error didn't show on it. For installing pgadmin 4, I used docker approach.
docker pull dpage/pgadmin4
docker run -p 5050:80 -e "PGADMIN_DEFAULT_EMAIL=XXXX#Xmail.com" -e "PGADMIN_DEFAULT_PASSWORD=thirumal" -d dpage/pgadmin4
Now, open the browser and navigate http://localhost:5050/.
I'm trying to setup an easily-replicable (or even manual and I do it once a month or so) process for moving data from a large Azure PostgreSQL database to a more manageable Azure SQL database for end users that are most familiar with SQL Server. I've successfully connected to the PostgreSQL database via PGAdmin, so I know all my connection string info.
I started by installing the latest ODBC driver from here.
I then used a connection string which was given to me from the Azure portal, filled in the proper database name and password, and attempted to use the following drivers:
PostgreSQL ODBC Driver(UNICODE)
PostgreSQL ODBC Driver(ANSI)
I am getting the following error with either of them:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
What step am I missing in this process? Or how best can I troubleshoot this?
After more research, I attempted to add the ODBC driver here:
And got the following error (I'm not sure why Tableau is relevant to this?):
Thank you.
I am using pgProvider on a MVC3 Mono application and had no issues on Windows Postgres 9.2. I am migrating to my production Linux/Mono environment, and received an error when attempting to access the provider:
"42704: language "plpgsql" does not exist"
I am using postgreSQL 8.4 on CentOS 6.3
I looked at some info, and ran the following:
createlang -d dbname plpgsql
When I run it again, it affirms that the database is already there.
I restarted postgresql and my app. However, I still get the above error.
Does anyone have any info on why I would still receive an "plpgsql does not exist -- after it is installed?"
In general this sort of error is an indication that something is not as you expect and you need to challenge your assumptions.
Please note that languages do not require restarting the database server to take effect on any version of PostgreSQL. Also note that what languages are allowed in PostgreSQL is a per-db catalog entry (languages, unlike users and roles, are not cluster-global).
So in troubleshooting this, you need to start with:
Is this the right db? The right server?
Is my application connecting to the same db/server I think it is?
Given that createlang affirms that the language exists after you run it, this can't be an issue with PostgreSQL raising a phony error. Instead it must be a problem with the changes you made not affecting the database your application is using.