Bug in 9i JDBC

Has anyone else seen this? We have just moved to Oracle 9i, and gotten the 9i drievrs. When retrieving a value from a column whose type is java.sql.Types.LONGVARCHAR and whose value is null the value of
resultSet.getString("COL") is null
but resultSet.wasNull() returns false.
Anyone seen this? Is it a known bug?
-- bk

the last column was null, and the rs.wasNull still returned false. We had to change the code:
String value = resultSet.getString( _index );
if ( resultSet.wasNull() ) {
//... do some null logic
to
String value = resultSet.getString( _index );
if ( null == value ) {
//... do some null logic
-- bk

Similar Messages

Bug in Oracle JDBC thin driver (parameter order)

[ I'd preferably send this to some Oracle support email but I
can't find any on both www.oracle.com and www.technet.com. ]
The following program illustrates bug I found in JDBC Oracle thin
driver.
* Synopsis:
The parameters of prepared statement (I tested SELECT's and
UPDATE's) are bound in the reverse order.
If one do:
PreparedStatement p = connection.prepareStatement(
"SELECT field FROM table WHERE first = ? and second = ?");
and then bind parameter 1 to "a" and parameter to "b":
p.setString(1, "a");
p.setString(2, "b");
then executing p yields the same results as executing
SELECT field FROM table WHERE first = "b" and second = "a"
although it should be equivalent to
SELECT field FROM table WHERE first = "a" and second = "b"
The bug is present only in "thin" Oracle JDBC driver. Changing
driver to "oci8" solves the problem.
* Version and platform info:
I detected the bug using Oracle 8.0.5 server for Linux.
According to $ORACLE_HOME/jdbc/README.doc that is
Oracle JDBC Drivers release 8.0.5.0.0 (Production Release)
* The program below:
The program below illustrates the bug by creating dummy two
column table, inserting the row into it and then selecting
the contents using prepared statement. Those operations
are performed on both good (oci8) and bad (thin) connections,
the results can be compared.
You may need to change SID, listener port and account data
in getConnecton calls.
Sample program output:
$ javac ShowBug.java; java ShowBug
Output for both connections should be the same
--------------- thin Driver ---------------
[ Non parametrized query: ]
aaa
[ The same - parametrized (should give one row): ]
[ The same - with buggy reversed order (should give no answers):
aaa
--------------- oci8 driver ---------------
[ Non parametrized query: ]
aaa
[ The same - parametrized (should give one row): ]
aaa
[ The same - with buggy reversed order (should give no answers):
--------------- The end ---------------
* The program itself
import java.sql.*;
class ShowBug
public static void main (String args [])
throws SQLException
// Load the Oracle JDBC driver
DriverManager.registerDriver(new
oracle.jdbc.driver.OracleDriver());
System.out.println("Output for both connections should be the
same");
Connection buggyConnection
= DriverManager.getConnection
("jdbc:oracle:thin:@localhost:1521:ORACLE",
"scott", "tiger");
process("thin Driver", buggyConnection);
Connection goodConnection
= DriverManager.getConnection ("jdbc:oracle:oci8:",
"scott", "tiger");
process("oci8 driver", goodConnection);
System.out.println("--------------- The end ---------------");
public static void process(String title, Connection conn)
throws SQLException
System.out.println("--------------- " + title + "
Statement stmt = conn.createStatement ();
stmt.execute(
"CREATE TABLE bug (id VARCHAR(10), val VARCHAR(10))");
stmt.executeUpdate(
"INSERT INTO bug VALUES('aaa', 'bbb')");
System.out.println("[ Non parametrized query: ]");
ResultSet rset = stmt.executeQuery(
"select id from bug where id = 'aaa' and val = 'bbb'");
while (rset.next ())
System.out.println (rset.getString (1));
System.out.println("[ The same - parametrized (should give one
row): ]");
PreparedStatement prep = conn.prepareStatement(
"select id from bug where id = ? and val = ?");
prep.setString(1, "aaa");
prep.setString(2, "bbb");
rset = prep.executeQuery();
while (rset.next ())
System.out.println (rset.getString (1));
System.out.println("[ The same - with buggy reversed order
(should give no answers): ]");
prep = conn.prepareStatement(
"select id from bug where id = ? and val = ?");
prep.setString(1, "bbb");
prep.setString(2, "aaa");
rset = prep.executeQuery();
while (rset.next ())
System.out.println (rset.getString (1));
stmt.execute("DROP TABLE bug");
null

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Bug in Oracle JDBC thin driver 8.1.6 ?

Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Bug in Oracle JDBC Drivers with {ts ?}

Oracle fails to set bind variables correctly when using the {ts ?} in an insert. It works ok if you use {d ?}.
Ex:
String st = "INSERT INTO BL(NM,TSTAMP) VALUES (?,{ts ?} )";
System.out.println(dbConn.nativeSQL(st));
java.sql.PreparedStatement stmt = dbConnn.prepareStatement(st);
stmt.setString(1,"test");
stmt.setString(2,"2000-08-18 09:33:45");
int xx = stmt.executeUpdate();
Oracle Reports:
INSERT INTO BL (NM,TSTAMP) VALUES (:1,TO_DATE (?, 'YYYY-MM-DD HH24:MI:SS'))
ConnectionPoolManager failed:java.sql.SQLException: ORA-00911: invalid character
Notice the ? doesn't change to :2.
Whoops.
Also when does Oracle plan to implement {fn }
scalars. There are work arounds but they are not portable. If not soon we will switch our suggested database for our clients.
null

Horea
In the ejb-jar.xml, in the method a cursor is closed, set <trans-attribute>
to "Never".
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name></ejb-name>
<method-name></method-name>
</method>
<trans-attribute>Never</trans-attribute>
</container-transaction>
</assembly-descriptor>
Deepak
Horea Raducan wrote:
Is there a known bug in Oracle JDBC thin driver version 8.1.6 that would
prevent it from closing the open cursors ?
Thank you,
Horea

Fatal bug with shared JDBC Session Persistence

We are attempting to launch a three-tier site with two clusters, one at the
          web layer (JSP/servlet/images) and a separate cluster at the app server
          layer (EJBs). We are running WebLogic server 4.5.1 Service Pack 8 on Solaris
          2.7. In production we use Solaris JDK 1.2.1.04, and in development we use
          JavaSoft JDK 1.2.2. We are able to duplicate this problem with both JDKs. We
          are using the WebLogic kona/oracle driver for session persistence because
          the Oracle JDBC driver would not work for this purpose - we are using the
          Oracle OCI driver for our EJB persistence in a separate pool in the app
          server cluster.
          We attempted to configure our web cluster to work with in-memory session
          replication. We found the performance of the WebLogic proxy to be abysmal -
          causing a 5x to 10x performance degredation over shared JDBC persistence. We
          were running the proxy on WebLogic, which we were advised would be slow. Its
          performance is beyond slow, it is completely unusable and should NEVER be a
          recommended or even supported configuration. We do not wish to purchase
          separate licenses for iPlanet, refuse to run IIS in a production setting,
          and cannot use Apache until WebLogic 5.1, so we are stuck with shared JDBC
          persistence until we can upgrade to 5.1.
          Using JDBC session persistence with a shared persistent store amongst all
          the clustered web servers results in our users getting brand-new sessions
          populated with data from OTHER USERS' SESSIONS. This is very easy to
          replicate using the provided test JSP and java class. This behavior results
          in new users coming to the site and finding themselves logged in as other
          users.
          The test.jsp file simply accesses the session, prints out some information,
          and then adds a few values to the session. The JSP prints out the value of
          session.isNew(), the session's ID, and the number of values in the session
          space. If you hit this jsp with a new browser window, the session should be
          new, and the number of values should be zero.
          The test Java class hits a URL with this test.jsp file repeatedly, and
          checks to make sure that the session is empty. It keeps a counter of the
          number of hits which resulted in non-empty sessions and the total number of
          hits. Because this java class does not maintain cookie data of any kind and
          merely opens new HTTP connections, it should always receive a brand-new,
          non-empty session.
          When we set the JDBC session persistence property
          weblogic.httpd.session.persistentStoreShared=true and run the test, we see
          periodically see the test.jsp file receiving a brand-new (session.isNew() =
          true), yet non-empty (session.getValueNames().length != 0) session. This is
          extremely bad behavior and makes the shared JDBC session persistence setting
          worthless. We were able to duplicate this behavior with both a single server
          and multiple servers in a cluster.
          If we set weblogic.httpd.session.persistentStoreShared=false, then this test
          works fine. This also means that we cannot cluster web servers.
          To run the test, simply start a WebLogic instance using the provided
          properties file, put the jsp in the document-root somewhere, and then run
          SessionTest.java, providing the URL of the test JSP as the only command-line
          argument. You will need to modify the properties file to have the proper
          database settings and document-root. The java class will display a running
          tally of the number of hits, and the number of hits that result in
          non-empty, illegal sessions, with a total at the end.
          So, we are now in a position where we are completely unable to launch our
          site in a clustered, no-single-point-of-failure configuration. Obviously,
          clustering was one of the main reasons to choose WebLogic, and we are
          extremely distressed that we are unable to get this configuration to work.
          Any help would be appreciated.
          [web.standalone.properties]
          [SessionTest.java]
          [test.jsp]


I hope this is not too far fetched, but we are expieriencing a similar
          problem with jms (messages are mixed up between queues). This happens only
          if we are using message persistence in an oracle db (everything works ok
          when we are not using persistent messages). Could it be that there is a
          serious bug in the jdbc code/oracle driver code or connection handling
          (regarding multi threading)? This would explain that, whenever you use
          persistence with oracle databases, messages/sessions (or other) are mixed
          up.
          - Falk
          "Grant Kushida" <[email protected]> wrote in message
          news:[email protected]...
          > We are attempting to launch a three-tier site with two clusters, one at
          the
          > web layer (JSP/servlet/images) and a separate cluster at the app server
          > layer (EJBs). We are running WebLogic server 4.5.1 Service Pack 8 on
          Solaris
          > 2.7. In production we use Solaris JDK 1.2.1.04, and in development we use
          > JavaSoft JDK 1.2.2. We are able to duplicate this problem with both JDKs.
          We
          > are using the WebLogic kona/oracle driver for session persistence because
          > the Oracle JDBC driver would not work for this purpose - we are using the
          > Oracle OCI driver for our EJB persistence in a separate pool in the app
          > server cluster.
          >
          > We attempted to configure our web cluster to work with in-memory session
          > replication. We found the performance of the WebLogic proxy to be
          abysmal -
          > causing a 5x to 10x performance degredation over shared JDBC persistence.
          We
          > were running the proxy on WebLogic, which we were advised would be slow.
          Its
          > performance is beyond slow, it is completely unusable and should NEVER be
          a
          > recommended or even supported configuration. We do not wish to purchase
          > separate licenses for iPlanet, refuse to run IIS in a production setting,
          > and cannot use Apache until WebLogic 5.1, so we are stuck with shared JDBC
          > persistence until we can upgrade to 5.1.
          >
          > Using JDBC session persistence with a shared persistent store amongst all
          > the clustered web servers results in our users getting brand-new sessions
          > populated with data from OTHER USERS' SESSIONS. This is very easy to
          > replicate using the provided test JSP and java class. This behavior
          results
          > in new users coming to the site and finding themselves logged in as other
          > users.
          >
          > The test.jsp file simply accesses the session, prints out some
          information,
          > and then adds a few values to the session. The JSP prints out the value of
          > session.isNew(), the session's ID, and the number of values in the session
          > space. If you hit this jsp with a new browser window, the session should
          be
          > new, and the number of values should be zero.
          >
          > The test Java class hits a URL with this test.jsp file repeatedly, and
          > checks to make sure that the session is empty. It keeps a counter of the
          > number of hits which resulted in non-empty sessions and the total number
          of
          > hits. Because this java class does not maintain cookie data of any kind
          and
          > merely opens new HTTP connections, it should always receive a brand-new,
          > non-empty session.
          >
          > When we set the JDBC session persistence property
          > weblogic.httpd.session.persistentStoreShared=true and run the test, we see
          > periodically see the test.jsp file receiving a brand-new (session.isNew()
          =
          > true), yet non-empty (session.getValueNames().length != 0) session. This
          is
          > extremely bad behavior and makes the shared JDBC session persistence
          setting
          > worthless. We were able to duplicate this behavior with both a single
          server
          > and multiple servers in a cluster.
          >
          > If we set weblogic.httpd.session.persistentStoreShared=false, then this
          test
          > works fine. This also means that we cannot cluster web servers.
          >
          > To run the test, simply start a WebLogic instance using the provided
          > properties file, put the jsp in the document-root somewhere, and then run
          > SessionTest.java, providing the URL of the test JSP as the only
          command-line
          > argument. You will need to modify the properties file to have the proper
          > database settings and document-root. The java class will display a running
          > tally of the number of hits, and the number of hits that result in
          > non-empty, illegal sessions, with a total at the end.
          >
          > So, we are now in a position where we are completely unable to launch our
          > site in a clustered, no-single-point-of-failure configuration. Obviously,
          > clustering was one of the main reasons to choose WebLogic, and we are
          > extremely distressed that we are unable to get this configuration to work.
          > Any help would be appreciated.
          >
          >
          >
          >

Bug in Oracle JDBC Pooling Classes - Deadlock

We are utilizing Oracle's connection caching (drivers 10.2.0.1) and have found a deadlock situation. I reviewed the code for the (drivers 10.2.0.3) and I see the same problem could happen.
I searched and have not found this problem identified anywhere. Is this something I should post to Oracle in some way (i.e. Metalink?) or is there a better forum to get this resolved?
We are utilizing an OCI driver with the following setup in the server.xml
<ResourceParams name="cmf_toolbox">
<parameter>
<name>factory</name>
<value>oracle.jdbc.pool.OracleDataSourceFactory</value>
</parameter>
<parameter>
<name>driverClassName</name>
<value>oracle.jdbc.driver.OracleDriver</value>
</parameter>
<parameter>
<name>user</name>
<value>hidden</value>
</parameter>
<parameter>
<name>password</name>
<value>hidden</value>
</parameter>
<parameter>
<name>url</name>
<value>jdbc:oracle:oci:@PTB2</value>
</parameter>
<parameter>
<name>connectionCachingEnabled</name>
<value>true</value>
</parameter>
<parameter>
<name>connectionCacheProperties</name>
<value>(InitialLimit=5,MinLimit=15,MaxLimit=75,ConnectionWaitTimeout=30,InactivityTimeout=300,AbandonedConnectionTimeout=300,ValidateConnection=false)</value>
</parameter>
</ResourceParams>
We get a deadlock situation between two threads and the exact steps are this:
1) thread1 - The OracleImplicitConnectionClassThread class is executing the runAbandonedTimeout method which will lock the OracleImplicitConnectionCache class with a synchronized block. It will then go thru additional steps and finally try to call the LogicalConnection.close method which is already locked by thread2
2) thread2 - This thread is doing a standard .close() on the Logical Connection and when it does this it obtains a lock on the LogicalConnection class. This thread then goes through additional steps till it gets to a point in the OracleImplicitConnectionCache class where it executes the reusePooledConnection method. This method is synchronized.
Actual steps that cause deadlock:
1) thread1 locks OracleImplicitConnectionClass in runAbandonedTimeout method
2) thread2 locks LogicalConnection class in close function.
3) thread1 tries to lock the LogicalConnection and is unable to do this, waits for lock
4) thread2 tries to lock the OracleImplicitConnectionClass and waits for lock.
***DEADLOCK***
Thread Dumps from two threads listed above
thread1
Thread Name : Thread-1 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x30267fe8 Waiting for Monitor Lock on 0x509190d8 Java Stack at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - waiting to lock 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at oracle.jdbc.pool.OracleImplicitConnectionCache.closeCheckedOutConnection(OracleImplicitConnectionCache.java:1330) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.runAbandonedTimeout(OracleImplicitConnectionCacheThread.java:261) - locked 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleImplicitConnectionCacheThread.run(OracleImplicitConnectionCacheThread.java:81)
thread2
Thread Name : http-7320-Processor83 State : Deadlock/Waiting on monitor Owns Monitor Lock on 0x509190d8 Waiting for Monitor Lock on 0x30267fe8 Java Stack at oracle.jdbc.pool.OracleImplicitConnectionCache.reusePooledConnection(OracleImplicitConnectionCache.java:1608) - waiting to lock 0x30267fe8> (a oracle.jdbc.pool.OracleImplicitConnectionCache) at oracle.jdbc.pool.OracleConnectionCacheEventListener.connectionClosed(OracleConnectionCacheEventListener.java:71) - locked 0x34d514f8> (a oracle.jdbc.pool.OracleConnectionCacheEventListener) at oracle.jdbc.pool.OraclePooledConnection.callImplicitCacheListener(OraclePooledConnection.java:544) at oracle.jdbc.pool.OraclePooledConnection.logicalCloseForImplicitConnectionCache(OraclePooledConnection.java:459) at oracle.jdbc.pool.OraclePooledConnection.logicalClose(OraclePooledConnection.java:475) at oracle.jdbc.driver.LogicalConnection.closeInternal(LogicalConnection.java:243) at oracle.jdbc.driver.LogicalConnection.close(LogicalConnection.java:214) - locked 0x509190d8> (a oracle.jdbc.driver.LogicalConnection) at com.schoolspecialty.cmf.yantra.OrderDB.updateOrder(OrderDB.java:2022) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:119) at com.schoolspecialty.cmf.yantra.OrderFactoryImpl.saveOrder(OrderFactoryImpl.java:67) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.ECommerceUtil.saveOrder(Unknown Source) at com.schoolspecialty.ecommerce.beans.UpdateCartAction.perform(Unknown Source) at com.schoolspecialty.mvc2.ActionServlet.doPost(ActionServlet.java:112) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPostOrGet(Unknown Source) at com.schoolspecialty.ecommerce.servlets.ECServlet.doPost(Unknown Source) at javax.servlet.http.HttpServlet.service(HttpServlet.java:709) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:237) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at com.schoolspecialty.ecommerce.servlets.filters.EcommerceURLFilter.doFilter(Unknown Source) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:186) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:157) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:214) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:198) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:152) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:137) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:118) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:102) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.core.StandardValveContext.invokeNext(StandardValveContext.java:104) at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:520) at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:929) at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:160) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:799) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection(Http11Protocol.java:705) at org.apache.tomcat.util.net.TcpWorkerThread.runIt(PoolTcpEndpoint.java:577) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:683) at java.lang.Thread.run(Thread.java:534)

We used a documented option to abandon connects in the case of an unforeseen error. The consequence of using this option was not a graceful degradation in performance but a complete lockup of the application. The scenario in which we created a moderate number of abandoned connections was a rare error scenario but a valid test.
How could this not be a bug in the Oracle driver? Is dead-lock a desireable outcome of using an option? Is dead-lock ever an acceptable consequence of using a feature as documented?
Turns out other Oracle options to recover from an unexpected error also incur a similar deadlock (TimeToLiveTimeout).
I did a code review of the decompiled drivers and it clearly shows the issue, confirming the original report of this issue. Perhaps you have evidence to the contrary or better evidence to support your statement "not a bug in Oracle"?
Perhaps you are one of the very few people who have not experience problems with Oracle drivers? I've been using Oracle since 7.3.4 and it seems that I have always been working around Oracle JDBC driver problems.
We are using Tomcat with the OracleDataSourceFactory.

Bug in Oracle JDBC Driver: NullPointerException when calling clearParameters

There is a bug in the latest version of the JDBC driver that throws a NPE when calling PreparedStatement.clearParameters(). I don't need a response to this, since I have a workaround (just catching and ignoring the exception), but it should probably be fixed. I speculate that the problem only occurs when you try to call clearParameters() more than once on the same PS, but I haven't confirmed it.
It is probably an easy fix. Following is the stack trace:
java.lang.NullPointerException
at oracle.jdbc.dbaccess.DBData.clearItem(DBData.java:431)
at oracle.jdbc.dbaccess.DBDataSetImpl.clearItem(DBDataSetImpl.java:3528)
at oracle.jdbc.driver.OraclePreparedStatement.clearParameters(OraclePreparedStatement.java:3401)
at com.solarmetric.datasource.PreparedStatementCache$CachePreparedStatement.close(PreparedStatementCache.java:293)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedStatementBatch(SQLExecutionManagerImpl.java:666)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executePreparedStatement(SQLExecutionManagerImpl.java:514)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.executeInternal(SQLExecutionManagerImpl.java:406)
at com.solarmetric.kodo.impl.jdbc.SQLExecutionManagerImpl.flush(SQLExecutionManagerImpl.java:273)
at com.solarmetric.kodo.impl.jdbc.runtime.JDBCStoreManager.flush(JDBCStoreManager.java:421)
at com.solarmetric.kodo.runtime.PersistenceManagerImpl.flush(PersistenceManagerImpl.java:549)
at com.solarmetric.kodo.runtime.PersistenceManagerImpl.commit(PersistenceManagerImpl.java:412)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.testMakePersistentAssignsObjectId2(Unknown Source)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.testMakePersistentAssignsObjectId(Unknown Source)
at com.sun.jdotck.api.persistencemanager.MakePersistentAssignsObjectId.runTest(Unknown Source)
at com.sun.jdotck.api.persistencemanager.PersistenceManagerTest.run(Unknown Source)
at com.solarmetric.kodo.compatibility.JDOCompatabilityTestSuite$1.runTest(JDOCompatabilityTestSuite.java:493)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:325)
at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:524)
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Take a look at the method that is causing the NullPointerException:
public void clearItem(int i)
if (!m_dynamic && m_vector == null && i < m_vector.size())
m_vector.removeElementAt(i);
if (m_items != null && i >= m_items.length)
return;
m_items[i] = null;
return;
A NullPointerException will be thrown whenever clearParameters() is called when no parameters have yet been bound.
The first IF statement should read:
if (!m_dynamic && m_vector != null && i < m_vector.size())
A simple workaround would be to make sure that your parameter list is never empty before calling clearParameters(). Is there a patch for this anywhere?

Is it a bug for Oracle JDBC driver?

Hi,
I use the thin JDBC driver to connect my server, and try to obtain the meta data for the query data set. However, every time I issue 'getMetaData()' to get meta data, the following error is reported:
java.lang.NumberFormatException: For input string: "4294967295"
     at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
     at java.lang.Integer.parseInt(Integer.java:480)
     at java.lang.Integer.parseInt(Integer.java:518)
     at oracle.jdbc.driver.OracleResultSetMetaData.getPrecision(OracleResultSetMetaData.java:381)
     at genentity.GenEntityForm.getTableMetaData(GenEntityForm.java:445)
     at genentity.GenEntityForm.jButton2_actionPerformed(GenEntityForm.java:336)
and the program coding for this error is as follows:
sql = "SELECT * FROM " + tableName;
ps = conn.prepareStatement(sql);
rs = ps.executeQuery();
rsmd = rs.getMetaData(); <-- Error occurs in here.
Does anyone get an idea for this? Please help.
Thanks in advance,
Athens Yan.

Hi,
If u have applied the patch then there shud be no problem...try applying the patch again.

Bug in oracle jdbc faq

The faq uses oracle.jdbc.V8Compatibility as a connection property, but the correct is oracle.jdbc.V8Compatible

Hi Paal,
Thanks for the feedback, and apologies for the delay responding to you.
Can you please confirm if this issue relates to the Documentation related faq at http://otn.oracle.com/contact/htdocs/faqs#documentation
This particular forum relates only to issues with the Online Documentation pages at: http://otn.oracle.com/documentation/index.html
If your feedback concerns other pages, please try another forum.
Thanks and regards,
Les

JDBC 8.1.6.0.1 Bug with grouping function

Hi,
I found a bug in the JDBC 8.1.6.0.1 driver, concerning the new grouping functionality of Oracle 8.1.6. Look at the following code fragment:
String cSelect = "SELECT DACO_VU_NAME AS DIM1, ' ' AS DIM2, TO_CHAR(DACO_VERKAUFSDATUM,'yyyymm') AS DIM_DATE, GROUPING(DACO_VU_NAME) AS DIM1GROUP, GROUPING(' ') AS DIM2GROUP, GROUPING(TO_CHAR(DACO_VERKAUFSDATUM,'yyyymm')) AS DIM_DATEGROUP, sum(DACO_BRUTTOBETRAG_TX) AS VALUE FROM DATENCONTAINER GROUP BY CUBE (DACO_VU_NAME, '-', TO_CHAR(DACO_VERKAUFSDATUM,'yyyymm') ) ORDER BY 1,2,3";
try {
System.out.println("SELECT: " + cSelect);
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery(cSelect);
while (rset.next()) {
String cTest1 = rset.getString("DIM1");
String cTest2 = rset.getString("DIM2");
String cTest3 = rset.getString("DIM_DATE");
String cChar1 = rset.getString("DIM1GROUP");
String cChar2 = rset.getString("DIM2GROUP");
String cChar3 = rset.getString("DIM_DATEGROUP");
System.out.println(cTest1 + "\t" + cTest2 + "\t" + cTest3 + "\t" + cChar1 + "\t" + cChar2 + "\t" + cChar3);
}When I compile this with the mentioned JDBC version and run it with java 1.2.2 (JDeveloper 3.1), i get the following output:
Ahrend GmbH & Co. KG 200003 0 0 0
Ahrend GmbH & Co. KG 200003 1 0 0
Ahrend GmbH & Co. KG 200004 0 0 0
Ahrend GmbH & Co. KG 200004 1 0 0
Ahrend GmbH & Co. KG null 0 0 1
Ahrend GmbH & Co. KG null 1 0 1
null 200003 0 1 0
null 200003 1 1 0
null 200004 0 1 0
null 200004 1 1 0
null null 0 1 1
null null 1 1 1As you can see, the grouping columns are mixed up. In this example, everywhere a normal row shows a "null" value, a corresponding grouping row should show a "1", but as you can see, for the last 6 rows, the ones are not in the first, but in the second grouping row.
When I compile the example with the Oracle 8.1.5 JDBC driver, I get the following, correct, output:
Ahrend GmbH & Co. KG 200003 0 0 0
Ahrend GmbH & Co. KG 200004 0 0 0
Ahrend GmbH & Co. KG null 0 0 1
Ahrend GmbH & Co. KG 200003 0 1 0
Ahrend GmbH & Co. KG 200004 0 1 0
Ahrend GmbH & Co. KG null 0 1 1
null 200003 1 0 0
null 200004 1 0 0
null null 1 0 1
null 200003 1 1 0
null 200004 1 1 0
null null 1 1 1The special thing about this example is, that I use a constant row for grouping (row 2). If you use a normal database row, everything works fine with 8.1.6.0.1, but nevertheless, this should be a bug.
Any comments on this are highly appreciated, since I need the JDK 1.2 for the application and I didn't find a working Oracle 1.2 JDBC version.
Thanks,
Thorsten.

Patches can be obtained from an Oracle Support Services technical analyst.
null

JDBC conversion bug?

Hi,
Please bear with the length of this post, but something really weird is happening and I think there may be a bug in the jdbc adaptor. I'm using the oracle9i-classes12.jar file, but have also tried the ojdbc14.jar file.
I have a number of schemas across a couple of databases (10i) and have a need to adminster a table that exists in each of the schemas through one application. We have recently moved a number of the schemas onto a new database machine as the old one was using a different character set than the other (both are now using AL32UTF8).
I'm using database links and synonyms in an administrative schema to access the common table in all the other schemas. The common table looks like:
CREATE TABLE patch_log
(patch_log_id NUMBER(12,0) NOT NULL,
patch_number NUMBER(12,0) NOT NULL,
date_applied DATE,
comments VARCHAR2(512),
applied_by VARCHAR2(40));
When my application does a fetch across all the tables, it generates a sql statement for each table synonym and bundles the results together into one array. The sql statement generated looks like:
SELECT applied_by,
comments,
date_applied,
patch_log_id,
patch_number
FROM table_synonym_name;
For the tables on one database, this statement works fine, for the others I get a SQLException bundled in a JDBCAdaptorException. I wanted to make sure that it wasn't the application (created with WebObjects) so I ran the sql statements in DbVisualizer as that also uses JDBC. I get the same error there. The error/stack trace is:
java.sql.SQLException: Invalid character encountered in: failAL32UTF8Conv
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134)
     at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:179)
     at oracle.jdbc.dbaccess.DBError.check_error(DBError.java:1130)
     at oracle.jdbc.dbaccess.DBConversion.failAL32UTF8Conv(DBConversion.java:2762)
     at oracle.jdbc.dbaccess.DBConversion.al32utf8BytesToJavaChars(DBConversion.java:2469)
     at oracle.jdbc.dbaccess.DBConversion.al32utf8BytesToJavaChars(DBConversion.java:2372)
     at oracle.jdbc.dbaccess.DBConversion.charBytesToJavaChars(DBConversion.java:884)
     at oracle.jdbc.dbaccess.DBConversion.CHARBytesToJavaChars(DBConversion.java:807)
     at oracle.jdbc.ttc7.TTCItem.getChars(TTCItem.java:298)
     at oracle.jdbc.dbaccess.DBDataSetImpl.getCharsItem(DBDataSetImpl.java:1493)
     at oracle.jdbc.driver.OracleStatement.getCharsInternal(OracleStatement.java:3355)
     at oracle.jdbc.driver.OracleStatement.getStringValue(OracleStatement.java:3556)
     at oracle.jdbc.driver.OracleResultSetImpl.getString(OracleResultSetImpl.java:434)
     at com.onseven.dbvis.sql.Selector.getValue(Unknown Source)
     at com.onseven.dbvis.sql.Selector.fetchData(Unknown Source)
     at com.onseven.dbvis.sql.Selector.execute(Unknown Source)
     at com.onseven.dbvis.sql.Selector.execute(Unknown Source)
     at com.onseven.dbvis.executor.ExecutorHandler.execute(Unknown Source)
     at com.onseven.dbvis.executor.ExecutorHandler.access$1000(Unknown Source)
     at com.onseven.dbvis.executor.ExecutorHandler$ExecutorThread.construct(Unknown Source)
     at se.pureit.swing.util.SwingWorker$2.run(Unknown Source)
     at java.lang.Thread.run(Thread.java:534)
Just to make things a little weird, if I qualify my search criteria with a patch_number, the statement works for all the tables:
SELECT applied_by,
comments,
date_applied,
patch_log_id,
patch_number
FROM table_synonym_name
WHERE patch_number = 100;
I can select from the patch tables without exception if I'm logged in as that schema owner regardless of how my sql statement is set up. It only happens when I try to access the tables via the link/synonym.
I did some playing around and discovered that if I order the columns differently in the sql statement (using the link/synonym), I can also avoid the error without a where clause:
SELECT patch_log_id,
patch_number,
date_applied,
applied_by,
comments
FROM table_synonym_name;
I have no idea why ordering the columns should or shouldn't make a difference. Not all the links/synonyms cause the exception, only those that were migrated to the new database (the old one had a different character set).
Could there be something to do with character sets that was exported/imported with those schemas that needs to be fixed? Why would the statements work with a where clause but not without?
Any help on this matter is greatly appreciated.

What was the old character set? How were the objects migrated to the new database?
Justin
Distributed Database Consulting, Inc.
http://www.ddbcinc.com/askDDBC

Server Exception when using JDBC to Connect with SAP

Hello,
I am trying to connect to a view in an external database using JDBC. When I run the TestJDBC Tool, I get the following server exception:
com.microsoft.sqlserver.jdbc.SQLServerException: ?? ?? '<view_name>'?(?) ???????.
    at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerStatement.getNextResult(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerStatement.doExecuteStatement(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerStatement$StmtExecCmd.doExecute(Unknown Source)
   at com.microsoft.sqlserver.jdbc.TDSCommand.execute(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerConnection.executeCommand(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeCommand(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeStatement(Unknown Source)
   at com.microsoft.sqlserver.jdbc.SQLServerStatement.executeQuery(Unknown Source)
   at com.sap.ip.bi.sdk.trialarea.connector.servlet.model.JDBCModel.getColumns(JDBCModel.java:202)
   at com.sap.ip.bi.sdk.trialarea.connector.servlet.controller.Control3.doPost(Control3.java:25)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:760)
   at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
   at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.runServlet(HttpHandlerImpl.java:401)
   at com.sap.engine.services.servlets_jsp.server.HttpHandlerImpl.handleRequest(HttpHandlerImpl.java:266)
   at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:386)
   at com.sap.engine.services.httpserver.server.RequestAnalizer.startServlet(RequestAnalizer.java:364)
   at com.sap.engine.services.httpserver.server.RequestAnalizer.invokeWebContainer(RequestAnalizer.java:1039)
   at com.sap.engine.services.httpserver.server.RequestAnalizer.handle(RequestAnalizer.java:265)
   at com.sap.engine.services.httpserver.server.Client.handle(Client.java:95)
   at com.sap.engine.services.httpserver.server.Processor.request(Processor.java:175)
   at com.sap.engine.core.service630.context.cluster.session.ApplicationSessionMessageListener.process(ApplicationSessionMessageListener.java:33)
   at com.sap.engine.core.cluster.impl6.session.MessageRunner.run(MessageRunner.java:41)
   at com.sap.engine.core.thread.impl3.ActionObject.run(ActionObject.java:37)
   at java.security.AccessController.doPrivileged(Native Method)
   at com.sap.engine.core.thread.impl3.SingleThread.execute(SingleThread.java:104)
   at com.sap.engine.core.thread.impl3.SingleThread.run(SingleThread.java:176)
The question marks really make it difficult to determine exactly what the issue is.
Is there a way to perform a trace or to determine what is going on? Our third party provider has already confirmed that the authorization they provided is correct and is working.
Thanks!

Yes you can run a profiler trace on the SQL Server and include the "User Error Message" event under "Errors and Warnings". This will show you the error message that SQL Server is sending to the client.
When you get it, post it here because this is might be a bug in our JDBC driver that it does not turn that error into a sensible com.microsoft.sqlserver.jdbc.SQLServerException.
David
David http://blogs.msdn.com/b/dbrowne/

Bad support for ts hint in Oracle jdbc driver (for preparedStatement)

hi
I have the following SQL
SELECT TRUNC({ ts '2004-01-01 00:00:00.0' }) FROM ET1_ELEMENT
With the jdbc.odbc driver the following meta data is returned:
ResultSet meta data are...
Column [1]
name [TRUNC(TO_DATE('2004-01-0100:00]
type [93]
class name [java.sql.Timestamp]
which is fine.
Nevertheless with Oracle thin driver I got an SQL exception:
The SQL Error is:
ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTAMP
internal exception:
(class java.sql.SQLException):
java.sql.SQLException: ORA-00932: inconsistent datatypes: expected NUMBER got TIMESTAMP
If I use the TO_DATE in the sentence (e.g. t_date('2004-01-01 00:00:00','YYYY-MM-DD HH24:MI:SS')) everything is fine on both driver.
Any idea on the problem? Is it a bug?
Thanks

Mikael,
I couldn't ascertain your environment from your post, so the below may be irrelevant for you. But in the hope that is isn't...
I tried your example on an Oracle 9i (9.2.0.4) database on SUN [sparc] Solaris 9, with J2SE 1.4.2_04 and the "ojdbc14.jar" [JDBC] driver. If I remove the "trunc" function, then I do not get an Oracle error. I must admit, though, that I don't understand why you need to trunc(ate) a literal value. All that the "trunc" function does is set the time part -- the hours, minutes, seconds, etc. -- of your timestamp to (all) zeroes -- which is what you have in your literal, anyway, so why the need for "trunc"?
I believe the Oracle JDBC driver converts the java sql-escape syntax -- "{ts '2004-01-01 00:00:00.0'}" -- to a call to the "to_date" function, anyway. Possibly one way to verify this would be to use P6 Spy. If I am correct, then it would only be logical that Oracle allows you to use the sql-escape syntax wherever it is all right to use the "to_date" function. But then again, I guess that
select trunc(to_date('2004-01-01 00:00','YYYY-MM-DD HH24:MI')
from ET1_ELEMENTis allowable syntax anyway. So I guess maybe that this may be a bug in the JDBC driver. Have you checked the MetaLink Web site?
Good Luck,
Avi.

JDBC driver 8.1.6.2.0 problems

I've upgraded my JDBC client to use the
latest 8.1.6 driver (8.1.6.2.0).
I upgraded my client software to use this
driver because the older versions would
"leak" connection processes on the system.
The website states this bug has been fixed,
but this bug still occurs in my
environment.
Has anyone experienced similar problems?
Here a short explanation of the bug
from the JDBC driver readme.
Bug 113152
Invalid connection consume a process
leading to ORA-20
Description:
Each invalid connection (which can't be closed,
e.g. incorrect password) consumes a process on the
system. When the number of processes exceeds processes
parameter in the init.ora, ora-20 ORA-00020: maximum
number of processes (50) exceeded.
null

We haven't released 8.1.6.2 yet. We should be wrapping up new work on this version and moving into the testing phase shortly.
Justin Cave
ODBC Development

Strange behaviour of JDBC query for CHAR column

Hi,
I have a simple table with char type and several records in the table.
create table char_test(str char(50));
insert into char_test values ('abc');
insert into char_test values ('abc ');
insert into char_test values ('abc ');
In JDBC, if I have a query like
PreparedStatement st = conn.prepareStatement("select str from char_test where str = 'abc'");
ResultSet rs = st.executeQuery();
All three rows will be returned.
However, If I use parameter for the PreparedStatment, nothing will be returned if the value of the parameter is passed as "abc".
PreparedStatement st = conn.prepareStatement("select str from char_test where str = ?");
st.setString(1, "abc");
ResultSet rs = st.executeQuery();
Personally, I think this is a bug of Oracle JDBC driver. Could anybody please give me any explanation?
Thanks,
Bill
PS. I'm using Oracle 10g Release 2 DB and ojdbc14.jar under jdk 1.5.

Hello Bill,
Have you solved your problem ?
I have encountered a similar one and found a strange behavior of JDBC driver for PrepareStatement : in some cases, deep in JDBC driver, the parameter values could'nt be convert and are send as null values to the server.
Here are partial driver logs, the first for a program which works fine and the second for one which turns on error.
============================
<record>
<date>2006-09-06T16:27:43</date>
<millis>1157552863218</millis>
<sequence>335</sequence>
<logger>oracle.jdbc.conversion</logger>
<level>FINE</level>
<class>oracle.jdbc.driver.DBConversion</class>
<method>javaCharsToCHARBytes</method>
<thread>10</thread>
<message>DBConversion.javaCharsToCHARBytes(chars[]= (26 bytes):
00 0c 00 65 00 78 00 70 00 73 00 74 00 6f 00 0a 00 73 00 6c
00 65 00 65 00 70 , charOffset=1, bytes[]= (7 bytes):
00 00 00 00 00 00 00 , byteOffset=0, cs=178, nchars=6)</message>
</record>
<record>
<date>2006-09-06T16:27:43</date>
<millis>1157552863218</millis>
<sequence>336</sequence>
<logger>oracle.jdbc.conversion</logger>
<level>FINE</level>
<class>oracle.jdbc.driver.DBConversion</class>
<method>javaCharsToCHARBytes</method>
<thread>10</thread>
<message>DBConversion.javaCharsToCHARBytes(chars, nchars, bytes[], cs): returned 6</message>
</record>
=============================
javaCharsToCHARBytes gets 6 characters OK
=============================
<record>
<date>2006-09-06T16:12:32</date>
<millis>1157551952843</millis>
<sequence>333</sequence>
<logger>oracle.jdbc.conversion</logger>
<level>FINE</level>
<class>oracle.jdbc.driver.DBConversion</class>
<method>javaCharsToCHARBytes</method>
<thread>10</thread>
<message>DBConversion.javaCharsToCHARBytes(chars[]= (40 bytes):
00 26 00 73 00 74 00 6f 00 72 00 61 00 67 00 65 00 5f 00 53
00 74 00 6f 00 72 00 65 00 2e 00 71 00 75 00 65 00 72 00 79 , charOffset=1, bytes[]= (20 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 , byteOffset=0, cs=178, nchars=19)</message>
</record>
<record>
<date>2006-09-06T16:12:32</date>
<millis>1157551952843</millis>
<sequence>334</sequence>
<logger>oracle.jdbc.conversion</logger>
<level>FINE</level>
<class>oracle.jdbc.driver.DBConversion</class>
<method>javaCharsToCHARBytes</method>
<thread>10</thread>
<message>DBConversion.javaCharsToCHARBytes(chars, nchars, bytes[], cs): returned 0</message>
</record>
=============================
javaCharsToCHARBytes gets 0 characters instead of 19
But I am unable to discover the differences between the 2 programs in the JDBC driver usage.
Does this sounds familiar to someone ?
François

Bug in 9i JDBC

Similar Messages

Maybe you are looking for