Oracle JDBC version 8.1.6

I have been using Oracle8i JDBC release 2 (8.1.6) for my application.
I am using Oracle Thin driver.
I have an application (in Unix) which continously pools a database .
I did not have any problem when I was connecting to Oracle 8.1.6 on NT
But now when I connected to Oracle 8.1.7 on Windows 2000 with the same
driver , I have a problem.
Its connects for lot of iterations but after quite a few iterations .I don't get a
connection while calling DriverManager.getConnection method ...
It hangs in that statement(DriverManager.getConnection).
I don't even get a error..
Can you advice on this problem.
Is this the driver version problem.? or some thing else

Did you load XML Developer's kit onto the database ?
You can get it from http://technet.oracle.com/tech/xml/xdk_java/

Similar Messages

Error while registering Oracle JDBC Diagnosability MBean - version 1.2.1

Hi,
I am running version 1.2.1 of SQL Developer (build MAIN-32.13). I have a local copy of Oracle 11g running on Windows XP. I am running version 1.6.0_03 of java.
When I fire it up, I get the following message in the "logging page - log" pane:
Source: oracle.jdbc.driver.OracleDriver
Message: Error while registering Oracle JDBC Diagnosability MBean.
Is this something I should worry about?
Graham

I got the same thing using SQLDeveloper shipped with 11g. It is every annoying since sqlplusw.exe is not available anymore, neither iSQLPLUS or SQLPLUS.exe is good enough all of the sudden that I found not much choice of accessing the database on windows ...

Is there any incompatibility in using different JDBC and Oracle database versions?

Hi everybody,
I hope you can answer me ASAP.
Which version of JDBC driver for Oracle could I use to access an Oracle database version 8.0.4.3.0 running on a SUN machine?
Is it necessary to use the specific driver concerning to that version or could we use the JDBC version 8.1.6?
If we decide to use JDBC 8.1.6 to work against the 8.0.4.3.0 database, will we find any incompatibility or problem?
Thanks.
null

I don't know the answer to your question, but while looking for something else, I found a table listing "requirements and compatibilities for oracle jdbc drivers" that might answer your question:
http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/java.817/a83724/getsta1.htm#1008206
(My aologies if that URL gets broken apart by this posting software and you have to piece it together.)
Hope this helps.

Oracle JDBC driver 11.2.0.3 is reported as client version 11.2.0.2

Greetings everyone,
I wonder if other folks are experiencing the same:
We have upgraded our JDBC driver to latest ojdbc6.jar (2,714,189 bytes) - 11.2.0.3
Everything looks great, except that on the server side it is reported as client version 11.2.0.2
JVM side:
===== Database info =====
DatabaseProductName: Oracle
DatabaseProductVersion: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
DatabaseMajorVersion: 11
DatabaseMinorVersion: 2
===== Driver info =====
DriverName: Oracle JDBC driver
DriverVersion: 11.2.0.3.0
DriverMajorVersion: 11
DriverMinorVersion: 2
Database side:
select client_driver, client_version from v$session_connect_info
(null), 11.2.0.2.0
Is that expected behavior or the property is not updated between releases?
Andrey
Edited by: 907164 on Jan 10, 2012 12:09 PM

Hi ,
Thank you so much for your reply.
That was the exact information that I needed.
Could you also tell me from where can I get the information of future releases.
Regards,
Stacey.

In Trouble with the Oracle JDBC Driver version - 10.1.0.5.0

Hi !
Without any problems i'm using the Oracle JDBC Driver version - 10.1.0.3.0 to access to the
Oracle database (Oracle Database 10g Release 10.2.0.1.0 - 64bit Production).
But exchanging the JDBC Driver 10.1.0.3.0 to 10.1.0.5.0 brings up the following problem:
the statement
con.prepareStatement(sql, resultSetType, resultSetConcurrency, resultSetHoldability)
(with parameters resultSetType = 1003, resultSetConcurrency = 1007, resultSetHoldability= 1)
returns null !
while using the Oracle JDBC Driver version - 10.1.0.3.0 the statement (with same parameters)
returns a correct PreparedStatement.
Every hint or idea is welcome.
Best regards,
Claus

Duplicate post:
In Trouble with the Oracle JDBC Driver version - 10.1.0.5.0
Claus,
Pardon me if I am stating the obvious, but why don't you use the 10.2 JDBC driver with your 10.2 database? The driver is part of the database distribution. Otherwise, you can download the driver from the OTN Web site.
Good Luck,
Avi.

How do I determine JDBC Version? - oracle.jdbc.driver

The following is my path and classpath and script.
Path = D:\oracle\ora90\bin;
D:\oracle\ora90\Apache\Perl\5.00503\bin\mswin32-x86;
C:\Program Files\Oracle\jre\1.1.8\bin;
%SystemRoot%\system32;
%SystemRoot%;
%SystemRoot%\System32\Wbem;
C:\Program Files\Common Files\AdaptecShared\System;
C:\Program Files\Java\j2re1.4.2\bin;
D:\oracle\ora90\LIB
classpath = .;
C:\Program Files\Java\j2re1.4.2\bin;
D:\oracle\ora90\jdbc\lib\
JDBCVersion.java
import java.sql.*;
import oracle.jdbc.driver.*;
class JDBCVersion
public static void main (String args[])
throws SQLException
//DriverManager.registerDriver
//(new oracle.jdbc.driver.OracleDriver());
// Load the Oracle JDBC driver
DriverManager.registerDriver
(new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection
("jdbc:oracle:thin:scott/tiger@t3100:1521:oracle");
// Create Oracle DatabaseMetaData object
DatabaseMetaData meta = conn.getMetaData();
// gets driver info:
System.out.println("JDBC driver version is " + meta.getDriverVersion());
this throws the following:
D:\oracle\ora90\jdbc\demo\samples\thin\basic\JDBCVersion.java:2: package oracle.jdbc.driver does not exist
import oracle.jdbc.driver.*;
^
D:\oracle\ora90\jdbc\demo\samples\thin\basic\JDBCVersion.java:14: package oracle.jdbc.driver does not exist
(new oracle.jdbc.driver.OracleDriver());

DON'T import the Oracle packages.
That's all hidden from you by the java.sql code. All you do is register the driver and get a connection:
Class.forName("driverClassName");
Connection connection = DriverManager.getConnection("url", "user", "pswd");You might have a "ClassNotFoundException" in your future. I'll bet the JDBC JARs aren't in your CLASSPATH. Make sure they're JARs, not zips. Oracle used to have everything in classes12.zip, but now they've gotten smart and put them in JARs for 9.2.0.1. - MOD

What version of Oracle JDBC driver

I need to know the version of the Oracle JDBC driver to use. I am using JDK version1.2, Oracle version8.0.5.

Subha,
You should be able to use any driver that directly supports JDBC 2.0. A Type-4 database-specific driver is not necessary.
Openlink Software provides a Type-3 JDBC 2.0 Driver Suite. Try a free non-expiring limited seat license at http://www.openlinksw.com under Software Availability and Download - Multi-Tier Download.
Regards,
Stephen Schadt
http://www.openlinksw.com

How to get comparable Oracle JDBC performance using Java 1.4 vs 1.1.7?

Our application makes extensive use of JDBC to access an Oracle database. We wrote it a number of years ago using java 1.1.7 and we have been unable to move to new versions of java because of the performance degradation.
I traced the problem to JDBC calls. I can reproduce the problem using a simple program that simply connects to the database, executes a simple query and then reads the data. The same program running under java 1.4 is about 60% slower than under java 1.1.7. The query is about 80% slower and getting the data is about 150% slower!
The program is attached below. Note, I run the steps twice as the first time the times are much larger which I attribute to java doing some initializations. So the second set of values I think are more representative of the actual performance in our application where there are numerous accesses to the database. Specifically, I focus on step 4 which is the execute query command and step 5 which is the data retrieval step. The table being read has 4 columns with 170 tuples in it.
Here are the timings I get when I run this on a Sparc Ultra 5 running
SunOs 5.8 using an Oracle database running 8.1.7:
                 java 1.1.7 java 1.4
        overall:    2.1s         3.5s
        step 1:     30           200
        step 2:    886          2009
        step 3:      2             2
        step 4:      9            17
        step 5:    122           187
        step 6:      1             1
        step 1:      0             0
        step 2:    203           161
        step 3:      0             1
        step 4:      8            15   <-   87% slower
        step 5:     48           117   <- 143% slower
        step 6:      1             2I find the same poor performance from java versions 1.2 and 1.3.
I tried using DataDirect's type 4 JDBC driver which gives a little better performance but overall it is still much slower than using java 1.1.7.
Why do the newer versions of java have such poor performance when using JDBC?
What can be done so that we can have performance similar to java 1.1.7
using java 1.4?
========================================================================
import java.util.*;
import java.io.*;
import java.sql.*;
public class test12 {
    public static void main(String args[]) {
        try {
                long time1 = System.currentTimeMillis();
/* step 1 */ DriverManager.registerDriver(
                    new oracle.jdbc.driver.OracleDriver());
                long time2 = System.currentTimeMillis();
/* step 2 */ Connection conn = DriverManager.getConnection (
              "jdbc:oracle:thin:@dbserver1:1521:db1","user1","passwd1");
                long time3 = System.currentTimeMillis();
/* step 3 */ Statement stmt = conn.createStatement();
                long time4 = System.currentTimeMillis();
/* step 4 */ ResultSet rs = stmt.executeQuery("select * from table1");
                long time5 = System.currentTimeMillis();
/* step 5 */ while( rs.next() ) {
                  int message_num = rs.getInt(1);
                  String message = rs.getString(2);
                long time6 = System.currentTimeMillis();
/* step 6 */ rs.close(); stmt.close();
                long time7 = System.currentTimeMillis();
            System.out.println("step 1: " + (time2 - time1) );
            System.out.println("step 2: " + (time3 - time2) );
            System.out.println("step 3: " + (time4 - time3) );
            System.out.println("step 4: " + (time5 - time4) );
            System.out.println("step 5: " + (time6 - time5) );
            System.out.println("step 6: " + (time7 - time6) );
            System.out.flush();
        } catch ( Exception e ) {
            System.out.println( "got exception: " + e.getMessage() );
        ... repeat the same 6 steps again...
}

If I run my sample program with the -server option, it
takes a lot longer (6.8s vs 3.5s).Which has to be expected, as the -server option optimizes for long running programs - so it shoudl go with my second suggestion, more below...
I am not certain what you mean by "just let the jvm
running". Our users issue a command (in Unix) which
invokes one of our java programs to access or update
data in a database. I think what you are suggesting
would require that I rewrite our application to have a
java program always running on the users workstation
and to also rewrite our
commands (over a hundred) to some how pass data and
receive data with this new server java program. That
does not seem a very reasonable just to move to a new
version of java. Or are you suggesting something
else?No I was just suggestion what you descript. But if this is not an option, then maybe you should merge your java-programs to C or another native language. Or you could try the IBM-JDK with the -faststart (or similar) option. If thew Unix you mention is AIX, then there would be the option of a resetable-vm. But I cannot say if this VM would solve your problem. Java is definitly not good for applications which only issue some unqiue commands because the hotspot-compiler can not be efficiently used there. You can only try to get 1.1.7 performance by experimenting with vm-parameters (execute java -X).

Help - Could not load 'oracle.jdbc.driver.OracleDriver ...

I'm using oci8 to connect to the Oracle database.
URL: jdbc:oracle:oci8:@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(PORT=1527)(HOST=testhost)))(CONNECT_DATA=(SID=fnoe2pa)))
When I tried to start the weblogic server, I got the following errors:
Can you suggest what I should do next (step-wise)??? Thanks, Bobby
<Sleeping in createResource()>
####<15/08/2002 14:09:43> <Error> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001060> <Cannot startup connection pool
"pool/test_myapp" weblogic.common.ResourceException:
Could not load 'oracle.jdbc.driver.OracleDriver
If this is a type-4 JDBC driver, it could occur if the JDBC
driver is not in the system CLASSPATH.
If this is a type-2 JDBC driver, it may also indicate that
the Driver native layers(DBMS client lib or driver DLL)
have not been installed properly on your system
or in your PATH environment variable.
This is most likely caused by one of the following:
1. The native layer SO, SL, or DLL could not be found.
2. The file permissions on the native layer SO, SL, or DLL
have not been set properly.
3. The native layer SO, SL, or DLL exists, but is either
invalid or corrupted.
For more information, read the installation documentation
for your JDBC Driver, available from:
http://e-docs.bea.com
     at weblogic.jdbc.common.internal.ConnectionEnvFactory.makeConnection(ConnectionEnvFactory.java:212)
     at weblogic.jdbc.common.internal.ConnectionEnvFactory.createResource(ConnectionEnvFactory.java:134)
     at weblogic.common.internal.ResourceAllocator.makeResources(ResourceAllocator.java:705)
     at weblogic.common.internal.ResourceAllocator.<init>(ResourceAllocator.java:282)
     at weblogic.jdbc.common.internal.ConnectionPool.startup(ConnectionPool.java:650)
     at weblogic.jdbc.common.JDBCService.addDeployment(JDBCService.java:107)
     at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:360)
     at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:285)
     at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:239)
     at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:199)
     at java.lang.reflect.Method.invoke(Native Method)
     at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
     at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
     at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:360)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
     at $Proxy31.updateDeployments(Unknown Source)
     at weblogic.management.configuration.ServerMBean_CachingStub.updateDeployments(ServerMBean_CachingStub.java:2977)
     at weblogic.management.mbeans.custom.ApplicationManager.startConfigManager(ApplicationManager.java:372)
     at weblogic.management.mbeans.custom.ApplicationManager.start(ApplicationManager.java:160)
     at java.lang.reflect.Method.invoke(Native Method)
     at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636)
     at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621)
     at weblogic.management.internal.ConfigurationMBeanImpl.invoke(ConfigurationMBeanImpl.java:360)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1557)
     at com.sun.management.jmx.MBeanServerImpl.invoke(MBeanServerImpl.java:1525)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:468)
     at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:209)
     at $Proxy42.start(Unknown Source)
     at weblogic.management.configuration.ApplicationManagerMBean_CachingStub.start(ApplicationManagerMBean_CachingStub.java:480)
     at weblogic.management.Admin.startApplicationManager(Admin.java:1234)
     at weblogic.management.Admin.finish(Admin.java:644)
     at weblogic.t3.srvr.T3Srvr.start(T3Srvr.java:524)
     at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:207)
     at weblogic.Server.main(Server.java:35)
>
####<15/08/2002 14:09:43> <Info> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001082> <Creating Data Source named
jdbc/test_myapp for pool pool/test_myapp>
####<15/08/2002 14:09:43> <Info> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001070> <Checking existence of connection pool
pool/test_myapp requested by user system>
####<15/08/2002 14:09:43> <Error> <JDBC> <qawebmethods> <myserver>
<main> <system> <> <001059> <Error during Data Source creation:
weblogic.common.ResourceException: DataSource(jdbc/test_myapp) can't
be created with non-existent Pool (connection or multi)
(pool/test_myapp)>
####<15/08/2002 14:09:50> <Info> <EJB> <qawebmethods> <myserver>
<main> <system> <> <010008> <EJB Deploying file: myapp-ejb.jar>
####<15/08/2002 14:09:50> <Warning> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160007> <You are running WebLogic Server with J2EE
1.3 features enabled. The implementation of specific J2EE 1.3 features
(EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0)
in BEA WebLogic Server 6.1 is of a non-final version of the
appropriate specification. It is subject to change in future releases
once the specification becomes finalized. This may cause application
code developed for BEA WebLogic Server 6.1 that uses the new features
of J2EE 1.3 to be incompatible with the J2EE 1.3 platform supported in
future releases of BEA WebLogic Server.>
####<15/08/2002 14:09:59> <Error> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160001> <Error deploying application myapp-ejb:
Unable to deploy EJB: Counter from myapp-ejb.jar:
The DataSource with the JNDI name: jdbc/test_myapp could not be
located. Please ensure that the DataSource has been deployed
successfully and that the JNDI name in your EJB Deployment descriptor
is correct.
>
####<15/08/2002 14:09:59> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101053> <[HTTP myserver] Loading web app: myapp>
####<15/08/2002 14:09:59> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101059> <[myserver] Loading myapp from WAR file:
C:\bea\wlserver6.1\.\config\mydomain\applications\.wlnotdelete\wlap31483\myapp.war>
####<15/08/2002 14:09:59> <Warning> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160007> <You are running WebLogic Server with J2EE
1.3 features enabled. The implementation of specific J2EE 1.3 features
(EJB 2.0, JSP 1.2, Servlet 2.3, and J2EE Connector Architecture 1.0)
in BEA WebLogic Server 6.1 is of a non-final version of the
appropriate specification. It is subject to change in future releases
once the specification becomes finalized. This may cause application
code developed for BEA WebLogic Server 6.1 that uses the new features
of J2EE 1.3 to be incompatible with the J2EE 1.3 platform supported in
future releases of BEA WebLogic Server.>
####<15/08/2002 14:09:59> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101031>
<[WebAppServletContext(1412030,myapp,/myapp)] extracting classfiles to
C:\bea\wlserver6.1\config\mydomain\applications\.wlnotdelete\wlap31483\WEB-INF\_tmp_war_myapp:>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101032>
<[WebAppServletContext(1412030,myapp,/myapp)] extracted classfiles
successfully...>
####<15/08/2002 14:10:04> <Info> <HTTP Session> <qawebmethods>
<myserver> <main> <system> <> <100037> <Creating SessionContext of
type: memory for webapp: /myapp>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering classpath
servlet with initArgs 'null'>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering getior
servlet with initArgs 'null'>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering tunneling
servlets with initArgs 'wl-dispatch-policy=direct'>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101047>
<[WebAppServletContext(1412030,myapp,/myapp)] registering JSPServlet
with initArgs '[JspConfig:
verbose=true,packagePrefix=jsp_servlet,-compiler=javac,compileFlags=,workingDir=C:\bea\wlserver6.1\config\mydomain\applications\.wlnotdelete\wlap31483\WEB-INF\_tmp_war_myapp,pageCheckSeconds=1,superclass=null,keepgenerated=false,precompileContinue=false,compilerSupportsEncoding=true,encoding=null,defaultfilename=index.jsp,compilerclass=null,noTryBlocks=false]'>
####<15/08/2002 14:10:04> <Debug> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101097> <Registering ServletContext:
"myapp:/myapp">
####<15/08/2002 14:10:04> <Info> <J2EE> <qawebmethods> <myserver>
<main> <system> <> <160003> <Deployed : myapp>
####<15/08/2002 14:10:04> <Info> <HTTP> <qawebmethods> <myserver>
<main> <system> <> <101133> <Initializing WEB server myserver>
####<15/08/2002 14:10:04> <Notice> <Management> <qawebmethods>
<myserver> <main> <system> <> <141052> <Application Poller started for
development server.>
####<15/08/2002 14:10:04> <Notice> <WebLogicServer> <qawebmethods>
<myserver> <ListenThread> <system> <> <000202> <ListenThread listening
on port 7001>
####<15/08/2002 14:10:04> <Info> <NT Performance Pack> <qawebmethods>
<myserver> <ListenThread> <system> <> <000000> <NATIVE: NTSocketMuxer
was built on Nov 1 2001 16:39:28
>
####<15/08/2002 14:10:04> <Notice> <WebLogicServer> <qawebmethods>
<myserver> <SSLListenThread> <system> <> <000202> <SSLListenThread
listening on port 7002>
####<15/08/2002 14:10:05> <Notice> <Management> <qawebmethods>
<myserver> <main> <system> <> <141030> <Starting discovery of Managed
Server... This feature is on by default, you may turn this off by
passing -Dweblogic.management.discover=false>
####<15/08/2002 14:10:05> <Notice> <WebLogicServer> <qawebmethods>
<myserver> <main> <system> <> <000331> <Started WebLogic Admin Server
"myserver" for domain "mydomain" running in Development Mode>
####<15/08/2002 14:10:11> <Info> <NT Performance Pack> <qawebmethods>
<myserver> <ExecuteThread: '14' for queue: 'default'> <> <> <000000>
<Allocating: '2' NT reader threads>
####<15/08/2002 14:10:13> <Info> <HTTP> <qawebmethods> <myserver>
<ExecuteThread: '1' for queue: '__weblogic_admin_html_queue'> <system>
<> <101047> <[WebAppServletContext(5367844,console,/console)] actions:
init>
####<15/08/2002 14:10:18> <Info> <HTTP> <qawebmethods> <myserver>
<ExecuteThread: '1' for queue: '__weblogic_admin_html_queue'> <system>
<> <101047> <[WebAppServletContext(5367844,console,/console)]
FileServlet: init>
####<15/08/2002 14:10:18> <Info> <HTTP> <qawebmethods> <myserver>
<ExecuteThread: '1' for queue: '__weblogic_admin_html_queue'> <system>
<> <101047> <[WebAppServletContext(5367844,console,/console)]
FileServlet: Using standard I/O>

"thorick" <[email protected]> wrote in message news:<[email protected]>...
Most likely, the OCI libraries could not be loaded.
Before continuing down this path, is there any reason
why you want to use an OCI based Driver as opposed to the
all Java Oracle thin driver ?There is indeed a valid reason for my choice.
I am currently connecting to the Oracle "Rdb" 7.0 database (located on
VMS) - not Oracle Oracle.
The SQL Service software we're currently using is version 7.1. This
version works well with the OCI8 driver (when connecting to the
database from Windows NT). This version of SQL Service however does
NOT work for the THIN driver (unless we upgrade the SQL Service to
version 7.1.5.5 - which we're not prepared to do so because it is not
stable enough from our previous test/trials). SQLSRV Version 7.1.5.5
works for THIN driver but it will result in uncommitted
transactions/unresolved connection/stopping of listener issues and
there is a need to restart the service from time to time. Oracle has
since confirmed that this is a bug that they have yet to resolve...
So we have to stick to OCI8 (THICK) for the time being. I would really
appreciate it very much if you can tell me the various OCI libraries
that I need to load (in terms of WebLogic Server config file settings
etc..).
By the way I have already installed the Oracle 8 client software on
the NT server (where WebLogic Server is) and I have also set up the
relevant SID (using the Net8 Assistant) that points to the Oracle Rdb
database on the VMS. I have also tried using SQL*Plus to connect to
the database and I can connect properly to the database. But WebLogic
simply doesn't seem to load the software.
Help...
Regards,
Bobby Brown, writing from Australia.

Oracle JDBC Driver 10.1.0.4.0 and IndexOutOfBounds-Exception

Hello all,
we´ve experienced a weird problem using the Oracle JDBC driver version 10.1.0.4.0. While executing SELECT statement we get an ArrayIndexOutOfBounds exception from the JDBC driver. Here´s the stacktrace:
java.lang.ArrayIndexOutOfBoundsException
at java.lang.System.arraycopy(Native Method)
at oracle.jdbc.driver.T4CDateAccessor.saveDataFromOldDefineBuffers(T4CDateAccessor.java:212)
at oracle.jdbc.driver.T4CPreparedStatement.saveDefineBuffersIfRequired(T4CPreparedStatement.java:405)
at oracle.jdbc.driver.OracleStatement.prepareAccessors(OracleStatement.java:859)
at oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:949)
at oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:532)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1037)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:2905)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:2946)
at weblogic.jdbc.wrapper.PreparedStatement.executeQuery(PreparedStatement.java:124)
We couldn´t find anything on the web on this error. We´re using Weblogic 8.1 SP4 with JDBC version. Does anyone have a hint or an idea what could be the problem here?
Thanks for any help in advance!
Cheers,
Joerg

I may have a related bug, I get a similiar exception when running JIRA...
java.lang.ArrayIndexOutOfBoundsException: -1
at oracle.jdbc.driver.DateTimeCommonAccessor.computeJulianDay(DateTimeCommonAccessor.java:341)
at oracle.jdbc.driver.DateTimeCommonAccessor.getMillis(DateTimeCommonAccessor.java:386)
at oracle.jdbc.driver.DateAccessor.getTimestamp(DateAccessor.java:142)
at oracle.jdbc.driver.OracleResultSetImpl.getTimestamp(OracleResultSetImpl.java:1018)...I tried the 10.1.0.2 and 10.1.0.4 drivers, both throw the same exception. I would try the 10.2 drivers, but they just hang! Gotta love Oracle QA!

How to install Oracle client Version 10.2.0.4 on a Windows server 2008

Hi,
I need to install an Oracle client on a Windows Server 2008 (32-bit), how do I do that?
I want to install Oracle client version 10.2.0.4 (Instant Client Package - Basic: All files required to run OCI, OCCI, and JDBC-OCI applications).
Pls. advice, I can't find instructions for this installation on Oracle.com or anywhere else.

thx, it looks promising...
but how to run the .jar files and which one to run, both Class12.jar and ojdbc14.jar, to start the installation?
Do I need to install the java runtime environment to run the .jar files?

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 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?

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

Differences between Oracle JDBC Thin and Thick Drivers

If any body is looking for this information...
============================================================
I have a question concerning the Oracle JDBC thin vs. thick drivers
and how they might affect operations from an application perspective.
We're in a Solais 8/Oracle 8.1.7.2 environment. We have several
applications on several servers connecting to the Oracle database.
For redundancy, we're looking into setting up TAF (transparent
application failover). Currently, some of our apps use the Oracle
<B>JDBC thin</B> drivers to talk to the database, with a connection
string that like this:
<B> jdbc:oracle:thin:@host:port:ORACLE_SID </B>
In a disaster recovery mode, where we would switch the database
from one server to another, the host name in the above string
would become invalid. That means we have to shut down our application
servers and restart them with an updated string.
Using the Oracle <B>OCI (thick)</B> driver though, allows us to connect
to a Net8 service instead of a specific server:
<B> jdbc:oracle:oci8:@NET8_SERVICE_NAME </B>
Coupled with the FAILOVER=ON option configured in Net8, it is
then possible to direct a connection from the first server to
the failover database on another server. This is exactly what
we would like to do.
My question is, from an application perspective, how is the Oracle
thick driver different from the thin driver? If everything
else is "equal" (i.e. the thick driver is compatible with the
app servers) would there be something within the the thick/OCI
driver that could limit functionality vs. the thin driver?
My understand, which obviously is sketchy, is that the thick
driver is a superset of the thin driver. If this is the case,
and for example if all database connections were handled through
a configuration file with the above OCI connection string, then
theoretically the thick driver should work.
============================================================
<B>
In the case with the Oracle, they provide a thin driver that is a 100% Java driver for client-side use without the need of an Oracle installation (maybe that's why we need to input server name and port number of the database server). This is platform indipendent, and has good performance and some features.
The OCI driver on the other hand is not java, require Oracle installation, platform dependent, performance is faster, and has a complete list of all the features.
</B>
========================================================
I hope this is what you expect.
JDBC OCI client-side driver: This is a JDBC Type 2 driver that uses Java native methods to call entrypoints in an underlying C library. That C library, called OCI (Oracle Call Interface), interacts with an Oracle database. <B>The JDBC OCI driver requires an Oracle (7.3.4 or above) client installation (including SQL*Net v2.3 or above) and all other dependent files.</B> The use of native methods makes the JDBC OCI driver platform specific. Oracle supports Solaris, Windows, and many other platforms. This means that the Oracle JDBC OCI driver is not appropriate for Java applets, because it depends on a C library to be preinstalled.
JDBC Thin client-side driver: This is a JDBC Type 4 driver that uses Java to connect directly to Oracle. It emulates Oracle's SQL*Net Net8 and TTC adapters using its own TCP/IP based Java socket implementation. <B>The JDBC Thin driver does not require Oracle client software to be installed, but does require the server to be configured with a TCP/IP listener. Because it is written entirely in Java, this driver is platform-independent.</B> The JDBC Thin driver can be downloaded into any browser as part of a Java application. (Note that if running in a client browser, that browser must allow the applet to open a Java socket connection back to the server.
JDBC Thin server-side driver: This is another JDBC Type 4 driver that uses Java to connect directly to Oracle. This driver is used internally by the JServer within the Oracle server. This driver offers the same functionality as the client-side JDBC Thin driver (above), but runs inside an Oracle database and is used to access remote databases. Because it is written entirely in Java, this driver is platform-independent. There is no difference in your code between using the Thin driver from a client application or from inside a server.
======================================================
How does one connect with the JDBC Thin Driver?
The the JDBC thin driver provides the only way to access Oracle from the Web (applets). It is smaller and faster than the OCI drivers, and doesn't require a pre-installed version of the JDBC drivers.
import java.sql.*;
class dbAccess {
public static void main (String args []) throws SQLException
DriverManager.registerDriver (new oracle.jdbc.driver.OracleDriver());
Connection conn = DriverManager.getConnection
("jdbc:oracle:thin:@qit-uq-cbiw:1526:orcl", "scott", "tiger");
// @machineName:port:SID, userid, password
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select BANNER from SYS.V_$VERSION");
while (rset.next())
System.out.println (rset.getString(1)); // Print col 1
stmt.close();
How does one connect with the JDBC OCI Driver?
One must have Net8 (SQL*Net) installed and working before attempting to use one of the OCI drivers.
import java.sql.*;
class dbAccess {
public static void main (String args []) throws SQLException
try {
Class.forName ("oracle.jdbc.driver.OracleDriver");
} catch (ClassNotFoundException e) {
e.printStackTrace();
Connection conn = DriverManager.getConnection
("jdbc:oracle:oci8:@qit-uq-cbiw_orcl", "scott", "tiger");
// or oci7 @TNSNames_Entry, userid, password
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select BANNER from SYS.V_$VERSION");
while (rset.next())
System.out.println (rset.getString(1)); // Print col 1
stmt.close();
=================================================================

Wow, not sure what your question was, but there sure was a lot of information there...
There really is only one case where failover occurs, and it would not normally be in a disaster recovery situation, where you define disaster recovery as the obliteration of your current server farm, network and concievably the operational support staff. This would require a rebuild of your server, network etc and isn't something done with software.
Fail over is normally used for high availablity that would take over in case of hardware server failure, or when your support staff wants to do maintenance on the primary server.
Using the thin and thick driver should have ZERO affect on a failover. Transparent failover will make the secondary server the same IP as the primary, therefore the hostname will still point to the appropriate server. If you are doing this wrong, then you will have to point all your applications to a new IP address. This should be something that you tell your management is UNACCEPTABLE in a fail-over situation, since it is almost sure to fail to fail-over.
You point out that you are providing the TNSNAME, rather than the HOSTNAME when using the thick driver. That's true within your application, but that name is resolved to either a HOSTNAME, or IP ADDRESS before it is sent to the appropriate Oracle server/instance. It is resolved using either a NAME server (same as DNS server but for Oracle), or by looking at a TNSNAMES file. Since the TNSNAMES files profilerate like rabbits within an organization you don't want a fail over that will make you find and switch all the entries, so you must come up with a fail over that does not require it.
So, the application should not be concerned with either the hostname, or the IP address changing during fail over. That makes use of the thin or thick client acceptable for fail over.
Don't know if this will help, but this shows the communication points.
THIN DRIVER
client --> dns --> server/port --> SID
THICK DRIVER
client --> names server --> dns --> server/port --> SID
client --> tnsnames --> dns --> server/port --> SID

Oracle JDBC version 8.1.6

Similar Messages

Maybe you are looking for