I am getting below exception while trying to insert records into database using CallableStatement.
Total records : 1300
To due to some security reasons not able to provide code snippet sorry for that but its normal CallableStatement executing perfectly for other flow in my project.
Throwing exception at 1327. stmt.executeBatch(). stmt is object of CallableStatement.
An ArrayIndexOutofBoundsException could be thrown by the Oracle JDBC driver.
Here you will get exact details of error from oracle.
It happens if the batch is too big. So either set the batch smaller in the OracleOutput component or try a different mode for inserting the data.
In order to resolve the issue, patch for BUG 6396242 must be downloaded from Oracle's support site and applied prior to using it.
You can resolve this problem by downloading the new version of ojdbc of 11 or greater version from OJDBC.
If you see this read me file here BUG-6396242, it has been fixed in Oracle JDBC Drivers release 11.1.0.7.0 - Production version.
Here i had attached screenshot of same.
Your problem could be related with the Oracle JDBC driver #6396242 bug: ArrayIndexOutOfBoundsException: -32nnn.
Please, try to download a patch for the bug from Oracle Support.
If you do not have access to Oracle Support, you can also download a recent version of the Oracle JDBC driver for your database version from the following link, it will also fix the problem.
This is a known issue in the mysql driver it has been fixed in 5.1.13 more details [here]
1, so to fix your bug simply upgrade it to the latest version.
You've got a bug. It is in your code.
Go to file com.mypackage.accounts.server.util.UtilClass.
Go to line 1356.
On it, you will find at least 1 array access (i.e. foo[x]). The number inside the []? It is -32593 for some reason. If there are more than 1 [] in that line, it's one of them, not possible to tell which one from this stacktrace.
Without you pasting the code we can't tell you why. I can tell you that PreparedStatement has nothing whatsoever to do with any of this.
Related
The question that I will ask does not contain any exception or anything. That's where the confusion coming from.
I have been migrating one old legacy application -which connects and writes to Database- to java8. It used to use the db2 library along with the license from /home/db2client/v95fp2/sqllib/java/db2jcc_license_cu.jar:/home/db2client/v95fp2/sqllib/java/db2jcc.jar. And when I check the details of the db2jcc.jar it says IBM DB2 JDBC Universal Driver Architecture.
Now, deleted that library from the classpath and added my new jar under the lib directory of the project db2jcc4-10.5fp11-fp11.jar and deleted the db2jcc_license_cu.jar And when I check the details of the new jar it says IBM Data Server Driver for JDBC and SQLJ. (The reason I changed to the new jar was there was some java8 combability problems in between the old one and java8)
Eventhough I do not have the license and the jars are different, my application still manages to run and write to the database without an exception. This is the reason I am very confused at the moment.
What is the difference between Universal Driver Architecture one and the Data Server Driver for JDBC SQLJ? And why is it still able to run? I have been reading the whole IBM manuals but I still do not know.
I am aware it may not be a type of question that is asked here, but I think that'd help me a lot to understand what's happening.
I wrote some code that connects to a PostgreSQL 9.4 DB via its latest JDBC4 driver. My understanding is that JDBC4 no longer needs the boilerplate "Class.forName("org.postgresql.Driver") driver registration line. Thus, I left it out. It worked fine.
I then put the same exact code in a servlet, added the postgreSQL JDBC jar to WebContent/WEB-INF/lib and it failed saying:
java.sql.SQLException: No suitable driver found for jdbc:postgresql://localhost/
When I add the Class.forName line, it then works fine.
Does anyone know why this JDBC4 driver needs Class.forName when put within a doGet() servlet method, but in a basic Java class it doesn't?
Thanks,
TR
edit: Forgot to mention, I'm using Java 7.
Some updates:
It does appear that this is a fairly common issue in Tomcat. I've moved the JAR out of WEB-INF/lib per the suggestions from this, and other posts. Even with it in TOMCAT_HOME/lib I need to use Class.forName(). Sort of odd, I suppose it has something to do with the way Tomcat registers classes.
Found this post which is the exact issue with the mySQL JDBC driver rather than postgreSQL:
When is Class.forName needed when connecting to a database via JDBC in a web app?
Thanks all for the help with this. I found the exact situation and answer in the Tomcat 7 documentation while learning how to setup a JNDI datasource:
http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html#DriverManager,_the_service_provider_mechanism_and_memory_leaks
In short, under these circumstances, you need to register the driver using Class.forName even if you are using JDBC4 on Tomcat 7.
Thanks everyone for pointing me in the right direction!
TR
I have a Rails 3.2.13 application written in JRuby (1.7.12). I'm developing on Mac OS X 10.10 (though the problem was also evident on 10.9). I have both JDK 1.6 and 1.7 installed. I'm serving the application via torquebox 3.1.1.
If I start the application connecting to my local postgres database, I have no issues. But I need to debug a problem that requires connecting to Oracle. I then switch my adapter to oracle-enhanced and making sure I have ojdbc6.jar and ojdbc7.jar in $JRUBY_HOME/lib. When I start the application via torquebox, I get errors like this:
14:47:58,242 ERROR [org.torquebox.core.runtime] (pool-8-thread-1) Error during execution: ENV['RAILS_ROOT']=RACK_ROOT
ENV['RAILS_ENV']=RACK_ENV
require %q(org/torquebox/web/rails/boot)
: org.jruby.exceptions.RaiseException: (NoMethodError) undefined method `blame_file!' forjava.lang.StackOverflowError:Java::JavaLang::StackOverflowError
I realize the blame_file! error is a separate thing. The StackOverflowError that's the cause of that error is what I care about. It's getting into a failing loop when trying to load necessary files, like rails/boot in this case.
However! When I run "rails console" it works fine and I can load data from the database.
I'm convinced as a result of being able to load the console that this is a problem with torquebox somehow, but I don't know what, nor how to fix it.
Is there any helps anyone can give me? Has anyone seen something like this before? Thanks.
(Edit, I found a locally cached copy of ojdbc7.jar in the app, which explains my original errors with 1.6. I've edited this post to reflect the current situation.)
Try looking at https://github.com/jruby/jruby/issues/976 to work around the blame_file problem and then hopefully you'll get a more useful error message.
Maybe then you'll get something be able to diagnose something similar to:
Error while loading java Class in Jruby application
I got some help on irc.freenode.net/#torquebox. After some confusion about the stack output vs. my stack size, it was suggested that I scale that back some. I set it from 4096m (yes, I realize now that that's ridiculous) to 2048k, and it works.
We don't know why Java crapped out in this specific way, but the end result is that with a smaller stack size, it works now.
I'm currently working with Java Stored Procedures in Oracle and am seeing some strange behaviour when attempting to get a connection within my Java code.
My Java is packaged up into a jar file and then deployed into Oracle using the loadjava command line utility. A package is then created in the database which maps each method in a designated Java class to a PL/SQL function via call specifications.
Some of the columns which I'm working with are CLOBs. In the Java I attempt to extract the value of this CLOB (mapped in call specification as oracle.sql.CLOB) into a String:
private static String getStringFromCLOB(CLOB clob) throws SQLException {
long length = clob.length();
return clob.getSubString(1, (int) length);
}
When I run this code I get the following stack trace showing up in SQL*Plus:
java.lang.ArithmeticException: / by zero
at oracle.jdbc.driver.T2SConnection.<init>(T2SConnection.java:107)
at oracle.jdbc.driver.T2SDriverExtension.getConnection(T2SDriverExtension.java:31)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java:481)
at oracle.jdbc.driver.OracleDriver.defaultConnection(OracleDriver.java:505)
at oracle.sql.DatumWithConnection.getPhysicalConnection(DatumWithConnection.java:53)
at oracle.sql.DatumWithConnection.getInternalConnection(DatumWithConnection.java:177)
at oracle.sql.CLOB.getDBAccess(CLOB.java:1383)
at oracle.sql.CLOB.length(CLOB.java:197)
Before I was just seeing the message of the Exception so I wrapped the offending method's contents with a try / catch so I could dump the full stack trace to the System.out.
It is worth noting that I have had this working on Oracle 11.2.0.1.0 (32bit) but it is not working on Oracle 11.2.0.2.0 (64bit).
I have also had other Java-backed PL/SQL functions working without a problem. It is only the ones that attempt to make a connection that fail.
I have had a look in <ORACLE_HOME>\jdbc\lib and the jars, although named the same, seem to be different in these two distributions. The jars in the directory are (11.2.0.1.0 size and 11.2.0.2.0 size shown):
ojdbc5.jar (1,950KB | 1,983KB)
ojdbc5_g.jar (3,010KB | 3,271KB)
ojdbc5dms.jar (2,374KB | 2,489KB)
ojdbc5dms_g.jar (3,030KB | 3,291KB)
ojdbc6.jar (2,062KB | 2,102KB)
ojdbc6_g.jar (3,323KB | 3,782KB)
ojdbc6dms.jar (2,594KB | 2,698KB)
ojdbc6dms_g.jar (3,344KB | 3,805KB)
simplefan.jar (20KB | 20KB) <-- probably the same
The manifest files of these jars confirm they are built for the specific version, i.e. 11.2.0.1.0 or 11.2.0.2.0. Is it possible a bug has been introduced in 11.2.0.2.0? Or is it more likely to be user, i.e. my, error :-)
Also, where does the oracle.jdbc.driver.T2SConnection class live?
Any help / guidance very much appreciated. Please let me know if you need more information.
I had this issue when my password was expiring. I solved this just changing the password.
Have similar problem with recent Oracle JDBC drivers. Our case seems to be a problem mixing jars from different versions, like 11.2.0.1 and 11.2.0.3, for example ojdbc6.jar from 11.2.0.1 and oi18n.jar from 11.2.0.3. One nice technique is decompiling the entire jars of the Oracle JDBC driver and look the line in the source code that is raising the error. Could provide a tip about the error/bug.
Try to use the same JDBC driver version in both client machines.
oracle.jdbc.driver.T2CConnection lives in any main jar of the driver, like ojdbc5.jar.
My Java/JDBC code suddenly stopped working from one day to another.
Same problem here. Expired password. I tried both ojdbc6 and ojdbc7. Upgraded my VM environment. The code worked fine against a different database.
target_user="c##ora$rman_bkp"
Placeholder START_DATE=20170422
Placeholder START_DATE_TIME=2017Apr22-20h47m13s
jdbcURL='jdbc:oracle:oci8:#twelve_static'
Exception in thread "main" java.lang.ArithmeticException: / by zero
at oracle.jdbc.driver.OraclePreparedStatement.<init>(OraclePreparedStatement.java:1387)
at oracle.jdbc.driver.T2CPreparedStatement.<init>(T2CPreparedStatement.java:109)
at oracle.jdbc.driver.T2CDriverExtension.allocatePreparedStatement(T2CDriverExtension.java:81)
at oracle.jdbc.driver.PhysicalConnection.prepareStatementInternal(PhysicalConnection.java:2013)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:1960)
at oracle.jdbc.driver.T2CConnection.prepareStatement(T2CConnection.java:57)
at oracle.jdbc.driver.PhysicalConnection.prepareStatement(PhysicalConnection.java:1866)
at oracle.jdbc.driver.T2CConnection.prepareStatement(T2CConnection.java:57)
at LV.verifyLicensedDbId(LV.java:238)
at RmanJ.<init>(RmanJ.java:1891)
at RmanJ.main(RmanJ.java:1809)
SYS#TWELVE:SQL> select account_status from dba_users where username='c##ora$rman_bkp';
ACCOUNT_STATUS
--------------------------------
EXPIRED(GRACE)
SYS#TWELVE:SQL> connect "c##ora$rman_bkp"
Enter password:
ERROR:
ORA-28002: the password will expire within 5 days
Connected.
c##ora$rman_bkp#TWELVE:SQL> password
Changing password for "c##ora$rman_bkp"
Old password:
New password:
Retype new password:
Password changed
Tested my code and it worked fine again. Yet another unbelievable bug in Oracle's software.
Their quality assurance never ever gets it right. I'm absolutely convinced that they don't even have proper test plans,
otherwise they would catch such severe errors as division by zero for an expired password.
To those that might come across this issue we discovered that it was caused by a corruption of the JVM install within Oracle. This probably occurred due to a bad installation.
Reinstalling the JVM aspect of Oracle allowed oracle.jdbc.driver.OracleConnection.defaultConnection() to run without any issues whether explicitly called or called as part of the stack of another call, e.g. oracle.sql.CLOB.length().
First, let me explain shortly how my application is working:
The application handles deals, which are stored as an XML document in our database (Oracle 11g). The table that contains these information is defined like that:
table T_MYDEALS (
DEAL_ID number(9, 0) not null,
DEAL_XML xmltype
)
When we update or insert new items in this table, we have a trigger that will read (using XPath) this XML, and populates some others metadata tables.
Everything works fine, except on my machine.
Now the problem
When I run the application on my machine (i.e. the Tomcat run within my Eclipse, but connected to the Homologation DB), the trigger fails with the following error:
WARN [org.hibernate.util.JDBCExceptionReporter] SQL Error: 1722, SQLState: 42000
ERROR [org.hibernate.util.JDBCExceptionReporter] ORA-01722: invalid number
ORA-06512: at "MY_SCHEMA.AFTER_R_INSERT_MYDEAL", line 628
ORA-04088: error during execution of trigger 'MY_SCHEMA.AFTER_R_INSERT_MYDEAL'
I'm sorry, I can't put my trigger here, for security reasons. Just note that the line 628 is at the end of the trigger code.
My tests
So I tried to understand why this error happened on my machine (as it only happen on my machine, none of my colleague encounter this issue). I can't say when it starts to stop working, maybe when I changed my computer recently?
First, I check the source code, then my DB connection, but everything seems correct.
I also switched in debug mode to have a look in the XML sent to the DB, or at least in our HibernateXMLType (which is an extension of org.hibernate.usertype.UserType, used to transform our XML into data readable by Oracle). But nothing wrong found here neither.
I save you many tests done on my side, but one of my latest tests was to get a fresh Tomcat server, and deploy a WAR that is deployed in an environment (Homologation for ex.).
Then, I executed the same tests, but the trigger is still failing.
So far, I have eliminated the following suspects:
The source code, as I also tested the application from a WAR that is deployed on an environment and which is working correctly;
The DB itself, as I am connected to the same DB as the working environment. I also tried with another DB, the result is the same.
The data used for my tests, as it works if I try to save the same deal, but using the Homologation environment.
JDK, as I also changed the JDK for a new one;
Eclipse, as my latest tests were done outside Eclipse;
Tomcat server, as I also tried on a new Tomcat.
What I am wondering is if my Windows XP environment has some specific encoding configuration, which "transforms" some data within the XML and make them
My questions
What are the possible elements that I may have forgotten in my tests?
Is there a way to know exactly the XML processed by the Oracle trigger (if possible without installing anything on the Oracle instance, as I don't have any control on it)?
I know that I don't provide a lot of information, but if you can give me some hints, or ideas, I would be really grateful!
Regards.
Technical information: Java 1.6, Oracle 11g, Tomcat 5.5.23, JSF 1.2, Hibernate 3.3
Could it be localization? On your system you're populating the xml with "1,5" instead of "1.5" for example. The error that is reported by Hibernate clearly points in that direction. You could disable the trigger and see what the resulting xmltype is in that table. And if you or one of your colleagues can access the database through an SQL Developer like client you could try and run the code in the trigger "manually".
See here for info and possible actions when you encounter ORA-01722.