postgres update query not works from Metabase - postgresql

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.

Related

Is there a way to use Flyway on AS400?

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

ERROR: cannot execute SELECT in a read-only transaction when connecting to DB

When trying to connect to my Amazon PostgreSQL DB, I get the above error. With pgAdmin, I get "error saving properties".
I don't see why to connect to a server, I would do any write actions?
There are several reasons why you can get this error:
The PostgreSQL cluster is in recovery (or is a streaming replication standby). You can find out if that is the case by running
SELECT pg_is_in_recovery();
The parameter default_transaction_read_only is set to on. Diagnose with
SHOW default_transaction_read_only;
The current transaction has been started with
START TRANSACTION READ ONLY;
You can find out if that is the case using the undocumented parameter
SHOW transaction_read_only;
If you understand that, but still wonder why you are getting this error, since you are not aware that you attempted any data modifications, it would mean that the application that you use to connect tries to modify something (but pgAdmin shouldn't do that).
In that case, look into the log file to find out what statement causes the error.
This was a bug which is now fixed, Fix will be available in next release.
https://redmine.postgresql.org/issues/3973
If you want to try then you can use Nightly build and check: https://www.postgresql.org/ftp/pgadmin/pgadmin4/snapshots/2019-02-17/

JDBC Producer in streamsets that could not write data into MySql

I had configured the JDBC connection configuration in the pipeline.
and when the application executes i get the following error on the logs.
"java.sql.SQLSyntaxErrorException: Table 'databaseName.aim_table' doesn't exist"
The databaseName is not what I have set.
I have tried many times. it shows the same message that could not find the table in different database, and the question is all the db occurred in the sdc.log are that I had never configured ,and the correct database is never used ,so I want to know how could it find the wrong db and I had checked before start the pipeline and it shows successful:
Do you have anything set in the Schema Name configuration for JDBC
Producer? This should be blank for MySQL, since you're setting the
database/schema name in the connect URL.
Check that your MySQL driver matches the server. In particular, using
the current version 8.0.x JDBC driver with a 5.x.x server seems to
result in this problem. Download the older 5.1.x driver (currently
5.1.46) and it should work.
refer this
This problem is indeed caused by the wrong version of the driver package. I found the correct driver package and successfully wrote the data to the target table. add aonther point, I have set the SCHEMA NAME to blank and defined the database name in the connect URL for mysql.
My English is not good. Please forgive me.

Connection validation error using postgresql jdbc 4.2 driver against a 9.3 database -- apparent case-sensitivity of SEARCH_PATH keyword

Using the jdbc4.2 implementation contained in postgresql-9.4.1212.jar, I generate an error when calling the java.Sql.Connection isValid() method on a connection to a postgresql 9.3 database (java8 and postgres both running on windows 7).
The path to producing the error is complicated but reproducible (will provide relevant code shortly) and involves a sequence of sql calls on a single db connection whose default schema is reconfigured prior to each use via an explicit execution of SET SEARCH_PATH='[some schema]'.
I find that the error occurs if and only if I render the SEARCH_PATH keyword using upper case (that is, the error does not occur if I execute SET search_path='[some schema]' - only when I execute SET SEARCH_PATH='[some schema]').
Note that the direct effect of executing either variant is the same -- in both cases the default schema associated with the connection is changed to [some schema]. It's just that, eventually, a downstream call to java.sql.connection.isValid() causes the database to crash if I've used SEARCH_PATH instead of search_path.
I can see that the jdbc driver's implementation of java.sql.connection.setSchema() uses the lower-case variant; something that makes me think this apparent case-sensitivity may be a known issue, but I have found no mentions of it anywhere online.
Note that the problem does not occur if I either: (1) use an older jdbc driver (postgresql-9.3.1100.jdbc4.1.jar) with my 9.3 database, or (2) use the latest jdbc driver with a postgresql 9.6 database.
I'm wondering if anyone has run into this specific problem, and also, if there are other known incompatibilities b/w the 9.3 database and the latest jdbc driver.
The driver is failing to invalidate the prepared statement cache because it only detects SET search_path=... when the config parameter is lower case.
See line 2056 of this commit.
I can't find an issue that describes this. Please have a look yourself and raise one if needed.

PostgreSQL: After using CreateLang, I still get an error "42704: language "plpgsql" does not exist"

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.