few days ago, I sent a query using presto.
it's really simple query like " select * from table limit 3; "
but, jdbc error was occured. I check my driver.
At that time, I used PrestoDB driver. Class name was 'com.facebook.presto.jdbc.PrestoDriver'
and I changed it to PrestoSQL driver using 'io.prestosql.jdbc.PrestoDriver' class.
I solved the query unexecution error. but, I'm curious why it wasn't work at the first time.
Anybody know why ?
com.facebook.presto.jdbc.PrestoDriver - is a PrestoDB, aka Presto(tm) driver, last update in 2018
io.prestosql.jdbc.PrestoDriver - is a PrestoSQL driver, last update in 2019 (now the name is Trino, rebranded in 2020)
io.trino.jdbc.TrinoDriver - Trino latest driver class.
So, which driver should be used depends on what you actually using: PrestoDB, PrestoSQL or Trino.
See also
Presto JDBC driver name change for 300+ version - I guess they meant Trino.
And thanks to #BrianOlsen for the comment with link, read the whole story: Announcing Trino - blog
Related
When I tried to upgrade my Oracle JDBC driver from ojdbc8 19.6.0.0 to ojdbc11 21.6.0.0.1 I started to receive the following exception when trying to do a batch insert with ids being generated in the database:
java.lang.AssertionError: autoKeyInfo is not initialized
I created a reproducer for this.
How can I resolve this problem?
This seems to be a bug in the later versions of the Oracle JDBC drivers.
They have the findings in the issue tracker, but I have nothing to link to since it is not public.
The recommended workaround is to use the LTS driver version, which is ojdbc 19.15.0.0.1
The reproducer is not just doing a batch update, it uses a Keyholder and tries to return the IDs generated by the database. The problem is not the generation of values, the problem is the attempt to return them.
https://docs.oracle.com/en/database/oracle/oracle-database/21/jjdbc/Oracle-extensions.html#GUID-9EC82134-1206-4325-A17B-9FA7610F0169 says "DML returning cannot be combined with batch update". "DML returning" refers to "returning into" clauses used by the driver to return values for out parameters. Looks like a conscious regression in the newer driver versions. Spring uses Keyholders to handle out parameters.
When creating the keys in the database with identity columns or triggers or with <sequence>.nextval in the SQL statement and not trying to return it the generated value, batch inserts should work.
After upgrading from Oracle 11/12 to 18/19 I get this error: ORA-01036: illegal variable name/number.
The error occurred in a query like this:
SELECT * FROM (SELECT * FROM TABLE) MY_TABLE WHERE ROWNUM <= :P_ROWNUM
(Subquery + binding parameters)
The identical query works properly with the Oracle 11.2.0.4 or 12.1.0.2 client. It fails with the Oracle Client 18c or 19c.
PS: The Oracle Server is version 18c 64x for Windows.
I use Delphi 10.1.2 with ADO components (dbGO). I also tried with Delphi 13.3.3 but the behavior is the same.
It seems to be a problem in the Oracle OLE DB provider (ORAOLEDB).
If I don't use ADO but DevArt Unidac all worked as expected.
Someone can help me?
Max
Your query is fine. We ran into a similar issue when migrating from 12.1 to 19. In our case, we have a custom OLE DB provider that interfaces with OraOLEDB (and others) using the Microsoft OLE DB Provider Templates (ATL). When attempting to upgrade from 12.1.x to 19c we started seeing the strange and confusing "ORA-01036: illegal variable name/number" error for parameterized SELECT queries. The queries would succeed the first time they were executed but subsequent executions would fail when all we did was change the parameter value (the queries were executed sequentially). I went on a wild goose chase trying to diagnose the issue and finally decided it had to be an Oracle caching bug of some kind. Yesterday, I experimented with the cache-related connection string attributes and found that adding the MetaDataCacheSize attribute and setting its value to 0 (zero) resolved the issue for us. None of the current Oracle patches appear to address this issue, at least none of those that mention the ORA-01036 error.
I am using Jaspersoft iReport Designer 5.0.0 and bqjdbc-0.1.jar (a BigQuery JDBC Driver) and I want to associate a query to a new report.
I currently have some problems when creating a new report with a query that has the keywords 'count' or 'as'. If I don't put these keywords my query works correctly.
What I find strange is that my problematic query will work if I select "Execute Command..." from my database connection in the Services window.
I also had the same problem with Jasper 4.8. I am not sure if the problem is with the BigQuery driver or with Jasper.
The error that I get when I try to associate the query to a new report is the following:
Message:
net.sf.jasperreports.engine.JRException: General problem: null
Check username and password; is the DBMS active ?!
Level: SEVERE
Stack Trace:
General problem: null Check username and password; is the DBMS active ?!
com.jaspersoft.ireport.designer.data.fieldsproviders.SQLFieldsProvider.getFields(SQLFieldsProvider.java:172)
com.jaspersoft.ireport.designer.connection.JDBCConnection.readFields(JDBCConnection.java:472)
com.jaspersoft.ireport.designer.wizards.ConnectionSelectionWizardPanel.validate(ConnectionSelectionWi zardPanel.java:146)
org.openide.WizardDescriptor$7.run(WizardDescriptor.java:1357)
org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:572)
org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:997)
This is interesting, could you give us an example of your query?
For me it seems that iReport wants to read something that isn't there.
The bigger problem is, that our logger doesn't really likes the iReport, but if you could check your log that would be a big help for us. For more information about the logging:
http://code.google.com/p/starschema-bigquery-jdbc/wiki/Logger
In the current 0.1 version we don't do anything with the query, just pass it to BigQuery. So if your query runs fine on the BigQuery Browser Tool, it should run fine with the Driver too.
Also, we don't really check stackoverflow, so please post your problems here, since we can answer your questions faster, over there:
http://code.google.com/p/starschema-bigquery-jdbc/issues/entry
I suddenly noticed that Oracle JDBC driver that I was using With Oracle 11g R2 was thinking that daylight savings time in US started after 2:59:59 am on March 13th this year. Actually, it started after 1:59:59 am. I did some additional testing and noticed that the buggy behavior of that driver did not depend on whether it talks to Oracle 11g R2 or Oracle 10g. Also, all available previous versions of that driver handle daylight savings time change correctly.
Is this a known bug? Is there a fix available for it?
Our DBA did research and found that this is a known bug and that a patch is available for it. Thanks everyone who cared to look into this and rake your brain for answers!
EDIT 9/25/2013: At the time of writing (over 2 years ago) a patch for the Oracle JDBC driver 11.2.0.2.0 was available to the paying Oracle customers. I have not tested personally, but I believe that the issue is resolved in the current version of the Oracle JDBC driver 11.2.0.4 which is available from Oracle for a free download.
Yes I agree that it is the driver. If your column is of type TIMESTAMP then Oracle will allow these invalid dates to get inserted into the DB then certain queries will throw
Error querying database. Cause: java.sql.SQLException: ORA-01878: specified field not found in datetime or interval
The error may involve defaultParameterMap
The error occurred while setting parameters
Cause: java.sql.SQLException: ORA-01878: specified field not found in datetime or interval
until the "bad" records are updated in the DB. This thread on stack overflow which was updated yesterday has the full detail. See the answer from Chris Williams
Oracle date compare broken because of DST
I have a web app hosted on BEA Weblogic 10.x with an Oracle 10g database backend.
It works perfectly with one database, but when we make a clone of it and try to use a different WebLogic and Oracle instance we are getting this error:
ERROR - Problem initializing invocation tracking - disabling
tracking xxxxclass.BadTableMappingException: Database column
xxxxPeriodEnding in database yyyyyyy, table zzzzzzz has an
unknown type: JDBC Type 91.
We get it every time we do a query that involves a column of type DATE. There was no ORA-XXXX code in the message.
I can access the database using SQL*Plus using the same access and do selects and updates on the same tables with no errors.
The answer to this question is not just a simple description of what a type 91 error is (although that will help) but what could be causing this given the circumstances described above.
I am using ojdbc14.jar for JDBC on both instances of weblogic.
I have no idea about the error, but have you considered the jdbc jar version and more importantly if the oracle DB needs to be updated.
I faced very weird problems with oracle, and struggled for a while to find at the end that installing some patches for oracle would solve the problem.
Set oracle.jdbc.V8Compatible=true.
This remaps the oracle DATE type to a DATETIME time in JDBC. This parameter was missing on the new Weblogic server.