JDBC Thin executeQuery ArrayIndexOutOfBoundsException

When we use the JDBC Thin Driver to perform executeQuery with a large number of columns in large select statement, we get an ArrayIndexOutOfBoundsException at index 960.
Is there something we can do to work around this problem?
Exception: array index is 960, array length is 960 after 0 rows
java.lang.ArrayIndexOutOfBoundsException: array index is 960, array length is 960
at oracle.jdbc.oracore.JavaConversion.UTF8toChar(Compiled Code)
at oracle.jdbc.ttc7.Odscrarr.decodeColName(Compiled Code)
at oracle.jdbc.ttc7.Odscrarr.decodeAllColumnNames(Compiled Code)
at oracle.jdbc.ttc7.Odscrarr.receive(Compiled Code)
at oracle.jdbc.ttc7.TTC7Protocol.describe(Compiled Code)
at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(Compiled Code)
at oracle.jdbc.driver.OracleStatement.doExecuteQuery(Compiled Code)
at oracle.jdbc.driver.OracleStatement.doExecute(Compiled Code)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(Compiled Code)
at oracle.jdbc.driver.OracleStatement.executeQuery(Compiled Code)
at SingleDataSource.executeQueryOpenCursor(SingleDataSource.java:234)
at ResultTable.executeQuery(Compiled Code)
at eeppi.util.swing.JBTableNoPrint.doQuery(Compiled Code)
at ResultTable.populateResultTable(Compiled Code)
at QueryPanel$searchActionListener.actionPerformed(Compiled Code)
at javax.swing.AbstractButton.fireActionPerformed(Compiled Code)
at javax.swing.AbstractButton$ForwardActionEvents.actionPerformed(Compiled Code)
at javax.swing.DefaultButtonModel.fireActionPerformed(Compiled Code)
at javax.swing.DefaultButtonModel.setPressed(Compiled Code)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Compiled Code)
at java.awt.AWTEventMulticaster.mouseReleased(Compiled Code)
at java.awt.Component.processMouseEvent(Compiled Code)
at java.awt.Component.processEvent(Compiled Code)
at java.awt.Container.processEvent(Compiled Code)
at java.awt.Component.dispatchEventImpl(Compiled Code)
at java.awt.Container.dispatchEventImpl(Compiled Code)
at java.awt.Component.dispatchEvent(Compiled Code)
at java.awt.LightweightDispatcher.retargetMouseEvent(Compiled Code)
at java.awt.LightweightDispatcher.processMouseEvent(Compiled Code)
at java.awt.LightweightDispatcher.dispatchEvent(Compiled Code)
at java.awt.Container.dispatchEventImpl(Compiled Code)
at java.awt.Window.dispatchEventImpl(Compiled Code)
at java.awt.Component.dispatchEvent(Compiled Code)
at java.awt.EventDispatchThread.run(Compiled Code)
null

Ashok,
Your database connection URL doesn't look right to me. The default database connection listener port is 1521 (not 9200). You can check this using the "lsnrctl" utility.
To find the "host" and SID parts (of the URL), use the following SQL query:
select HOST_NAME, INSTANCE_NAME from V$INSTANCEGood Luck,
Avi.

Similar Messages

JDBC thin drivers for oracle 8.0.5 for linux

I want to use Java SDK 1.2.2 and need the oracle thin drivers.
I have trouble with the 816 thin drivers connecting to the 8.0.5
server.
when using statement.executeQuery(..... I get the following
Exception.
Exception error: java.sql.SQLException: ORA-03120: two-task
conversion routine:integer overflow
I think my solution is to upgrade to a 8.1.6 server or use the
java 1.1.6 driver on the JDK1.1.6
I tried downoading the 8.1.5 enterprise server but this fails to
complete.
Can someone help me to this version on CDROM or to the JDBC thin
driver for the 8.0.5 server?
null

You must include "classes12.zip" instead of "classes111.zip".
Since "classes111.zip" is required only for Java 1
and "classes12.zip" is required for Java 2 which means from J2SE 1.2 on forward.
In adition you might need to inlcude "nls_charset12.zip" as well. Try it first without and if it is not working include it as well.
The required files can you get from the OTN.
This should help
Roger

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

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
JDBC thin drivers to talk to the database, with a connection
string that like this:
 jdbc:oracle:thin:@host:port:ORACLE_SID 
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 OCI (thick) driver though, allows us to connect
to a Net8 service instead of a specific server:
 jdbc:oracle:oci8:@NET8_SERVICE_NAME 
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.
============================================================

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.

========================================================
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. 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. 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. 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. 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

How does Oracle JDBC thin driver handle numbers via getString?

Hi,
I have a query regarding how numbers are handled by the oracle jdbc thin driver. The issue I am facing is with regards to the decimal separator (. is en_US and , in pt_BR)
e.g. Consider the below code,
Connection conn = DriverManager.getConnection(...);
Statement stmt = conn.createStatement();
ResultSet rset = stmt.executeQuery("select value from test_table1");
while (rset.next())
System.out.println (rset.getString(1));
test_table1 has a single column of sql type 'number' with a single row having value "123.45"
NLS_NUMERIC_CHARACTERS = ".,"
Database version = 10.2.0.2.0
There is a (generic) method to which a ResultSet is passed and it returns a dictionary of key value pairs. All column values from the ResultSet are retrieved using getString method of ResultSet.
My question is whether the jdbc driver formats numbers (based on the locale) before returning it as a string as part of the getString method?
e.g.
java -Duser.language=pt -Duser.region=BR TestJDBC
prints "123.45" and not "124,45"
Is there a reason why getString always retrieves a number column value with '.' as the decimal separator?
To help make things a bit more clear, all the column values retrieved are then converted into an XML (and hence the conversion to string)
At present, the only way I see out of this is to handle numbers differently.
i.e. something similar to,
if (resultsetmetadata.getcolumntype .. = double OR float OR int OR long.. )
NumberFormat.getInstance().format(rset.getDouble(1));
Is there a better way to resolve this issue?
Thanks,
Binoy

user565580,
As has been already stated, Oracle does not have data-types INTEGER or SMALLINT, only NUMBER.
So even though Oracle lets you write INTEGER, it really creates a NUMBER.
(As Joe mentioned.)
Other databases don't have a NUMBER data-type, they have INTEGER, SMALLINT, etc.
Originally, Oracle database only had three data-types:
CHAR
DATE
NUMBER
If you're going to be working with Oracle database, then you need to adapt yourself to its limitations.
So you'll probably need to define NUMBER data-types using scale and precision.
(As Kuassi mentioned.)
Good Luck,
Avi.

Connection error to 9i database using JDBC thin driver

When trying to connect to a new 9i database using the JDBC thin driver, I received the following error:
java.sql.SQLException: ORA-00600: internal error code, arguments: [ttcgcshnd-1], [0], [], [], [], [], [], []
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java)
at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java)
at oracle.jdbc.ttc7.Oall7.receive(Oall7.java)
at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java)
at oracle.jdbc.ttc7.TTC7Protocol.fetch(TTC7Protocol.java)
at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java)
at oracle.jdbc.driver.OracleStatement.doExecute(OracleStatement.java)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java)
at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java)
at oracle.jdbc.driver.OracleDatabaseMetaData.getTables(OracleDatabaseMetaData.java)
I have no problem with my code connecting to an Oracle 8 database, just 9i.
I'm trying to debug in Visual Cafe (JDK 1.1.7) and have both the classes111.zip and the nls_charset11.zip in my CLASSPATH.
Any suggestions would be appreciated. Thanks

If you're using 8i 8.1.7.1 or 8i 8.1.7.0 thin JDBC drivers on NT, then you can get them to connect to 9i by applying the 8i 8.1.7.1 Patch available at:
http://technet.oracle.com/software/tech/java/sqlj_jdbc/htdocs/solsoft.html
You might have to register/login first.
Basically, it's just a case of replacing a class already in your classes111.zip or classes12.zip with the class in the patch.
Took me a while to find this, but it worked first time after patching. Hope this helps.

ORACLE JDBC Thin 8.0.x - NOT Y2K compliant?

it seems that the oracle 8.0.x jdbc thin drivers are NOT Y2K
compliant...
i am using an 8.0.4/8.0.5 jdbc thin driver and jdk1.1.8
i use ResultSet for issuing SELECT statements:
ResultSet r = stmt.executeQuery("select date_field from....");
i set the date_field to year 2003
when i issue this in my java program:
java.sql.Date d = r.getDate("date_field");
the Date object returned in d has a year value of 1903!!!!!!!
of course there is a workaround...but ORACLE claims that their
jdbc drivers are Y2K compliant yet it fails
here.........frustrating...
null

dexter (guest) wrote:
: it seems that the oracle 8.0.x jdbc thin drivers are NOT Y2K
: compliant...
: i am using an 8.0.4/8.0.5 jdbc thin driver and jdk1.1.8
: i use ResultSet for issuing SELECT statements:
: ResultSet r = stmt.executeQuery("select date_field from....");
: i set the date_field to year 2003
: when i issue this in my java program:
: java.sql.Date d = r.getDate("date_field");
: the Date object returned in d has a year value of 1903!!!!!!!
: of course there is a workaround...but ORACLE claims that their
: jdbc drivers are Y2K compliant yet it fails
: here.........frustrating...
please disregard the previous message.
i think i was on drugs when i did the test...the field returns
1903 because the year value of the field is 1903...i changed the
date to 2003 and it all works fine now...
null

P-R-O-B-L-E-M with JDBC thin driver

Thank you gmagana!
I did not manage to make this code connect to Oracle at all:
import java.sql.*;
public class jdbcThin {
public static void connect() {
 String url = "jdbc:oracle:thin:uName/passW@myDatabase:1521:orcl";
 try {
 Class.forName ("oracle.jdbc.driver.OracleDriver");
 Connection conn = DriverManager.getConnection( url );
 System.out.println ("The Oracle thin driver loaded!");
 catch (ClassNotFoundException e) {
 System.out.println ("Did not load driver.");
 e.printStackTrace ();
 catch (SQLException e) {
 System.out.println ("Did not load driver.");
 e.printStackTrace ();
public static void main( String args[] ) {
 connect();
// Do "statement" stuff after I successfully connect to Oracle.
My setup:
1. jdbcThin.class in located in: ~/runMe/jdbcThin.class
2. Unextracted classes12.zip in: ~/runMe/classes12.zip
3. Java Runtime: ~/runMe/bin or
~/runMe/jre/bin
Command line:
%~/runMe> java jdbcThin
Message:
Did not load driver.
java.lang.ClassNotFoundException: oracle.jdbc.driver.OracleDriver
at jdbcThin.connect(Compiled Code)
at jdbcThin.main(Compiled Code)
%~/runMe>
Tried running it with classpath re-direction:
%~/runMe> java -classpath /runMe classes12.zip.jdbcThin
Message:
zip.jdbcThin
Can't find class classes12.zip.jdbcThin
%~/runMe>
I am not permitted to change anything in .cshrc or .profile where
I could use/> setenv classpath path1:path2: ~etc.
Oh, JAVA gods(!) I am stuck. <quite pissed> :(
...and what am I doing wrongly with JDBC thin?!
H E L P !!!!!!!!!!!!!!!!!!!

Thanks Shirish! (Symmetrical WRT sound!)
Here is my adaptation of that snippet which compiles, except for one error:
Class OracleDriver not found. How did you handled your classes12.zip and
your class path? Exactly what should happen at the command line?!
That is really my BIGGEST issue with these vendor drivers outside JDK.
I am aware that many styles work, but given the EXACTLY correct environment
setting. This is my main issue and why I specified my exact directories.
1. If Oracle is in: ~ root/Oracle
2. Thin driver in: ~ root/drivers/classes12.zip
3. My connection code in: ~root/sources/connDB.class
What EXACTLY should happen to compile and run:
import java.sql.*;
public class connDB {
public static void connect() {
 Connection conn;
 Statement stmt;
 ResultSet rtset;
 String SQL;
 try {
DriverManager.registerDriver(new OracleDriver());
conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:" + instance, username, password);
stmt = conn.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, ResultSet.CONCUR_UPDATABLE);
rtset = stmt.executeQuery(SQL);
catch( SQLException sqle ) {
 System.out.println ("Did not load driver.");
 sqle.printStackTrace ();
public static void main( String args[] ) {
 connect();
I am sitting @~root/sources>
So far I have no problem running any non-driver associated classes from there.
But how do I make my code find this OracleDriver?! And should classes12.zip
be extracted? I was told it should remain intact. Point is where should it be
or what command line "command" gets this connDB.class + OracleDriver to run?

JDBC thin driver connection problems using cybersafe authentication

Hi
i am trying to use jdbc thin driver to connect to oracle 8.1.7 DB using ASO and cybersafe authentication.
Question:
Does the oracle jdbc thin driver in 8.1.7.0.0 support third-party authentication features supported by Oracle Advanced Security--such
as those provided by RADIUS, Kerberos, or SecurID
i am getting the following error.
Exception in thread "main" java.sql.SQLException: invalid arguments in call
at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java)
at oracle.jdbc.dbaccess.DBError.check_error(DBError.java)
at oracle.jdbc.ttc7.TTC7Protocol.logon(TTC7Protocol.java)
at oracle.jdbc.driver.OracleConnection.<init>(OracleConnection.java)
at oracle.jdbc.driver.OracleDriver.getConnectionInstance(OracleDriver.ja
va)
at oracle.jdbc.driver.OracleDriver.connect(OracleDriver.java)
at java.sql.DriverManager.getConnection(DriverManager.java:517)
at java.sql.DriverManager.getConnection(DriverManager.java:146)
at ASOJdbc.main(ASOJdbc.java:43)
Following is the program i am trying.
public class ASOJdbc {
 public static void main(String args[]) throws SQLException {
 String url = "jdbc:oracle:thin:@son1129:1521:sonias";
 Connection con;
 String query = "select EMPNO, ENAME from EMP";
 Statement stmt;
 // ASO Stuff
 Properties props = new Properties();
 try {
 props.put("oracle.net.authentication_services", "CYBERSAFE");
 props.put("oracle.net.authentication_gssapi_service", "oracle/[email protected]");
 props.put("oracle.net.encryption_types_client", "DES");
 props.put("oracle.net.encryption_types_server", "DES");
 props.put("oracle.net.crypto_seed", "4fhXXXX");
 } catch (Exception e) { e.printStackTrace();
 DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());
 // ASO
 con = DriverManager.getConnection(url, props);
 stmt = con.createStatement();
 ResultSet rs = stmt.executeQuery(query);
 stmt.close();
 con.close();
jdk version: jdk 1.3.1
Oracle jdbc driver information, which i obtained as per Note 94091.1
=============
Database Product Name is Oracle
Database Product Version is Oracle8i Enterprise Edition Release 8.1.7.1.1 - Production With the Partitioning option
JServer Release 8.1.7.1.1 - Production
JDBC Driver Name is Oracle JDBC driver
JDBC Driver Version is 8.1.7.0.0
JDBC Driver Major Version is 8
JDBC Driver Minor Version is 1

1. What JDBC Thin client Driver are you using? (version) If you don't know, open up the Manifest.
2. the JDBC/OCI driver is a thick driver. It uses the oracle client, and therefore should read the tnsnames.ora
3. You have yet to give us any ORA- errors, which would help immensely in troubleshooting.

[End of TNS data channel] with Java SDO API (JDBC thin 9.0.1.2.1)

Hello folks,
Environment:
Win2K, 1.2GHz Intel, 500MB RAM, Oracle 9i, Oracle JDBC Thin (9.0.1.2.1), JDK1.3
Our data in the DB is 2-D. It consists of SDO LineString geometries. We use SRID = 8307.
I run into this problem with Java SDO API. I got this exception: "Io exception: End of TNS data channel"
when I try to execute query that uses the SDO_RELATE function:
SELECT e.shape
FROM edge e
WHERE SDO_RELATE(e.shape,
mdsys.sdo_geometry( 2003, 8307, NULL,
mdsys.sdo_elem_info_array(1,1003,1),
mdsys.sdo_ordinate_array(-125.8,49.9,-125.6,49.9,-125.6,50.0,-125.8,50.0,-125.8,49.9) ),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE'
If I use SDO_FILTER instead of SDO_RELATE it works!
Here is how I execute the query in Java:
public int executeSpatialQuery(OracleConnection conn, String spatialQuery) throws Exception
int numberOfGeometries = 0;
conn.setDefaultRowPrefetch(1000);
Statement ps = conn.createStatement();
ResultSet rs = ps.executeQuery(spatialQuery);
while (rs.next()) {
numberOfGeometries++;
rs.close();
ps.close();
return numberOfGeometries;
Note: I was playing with the "conn.setDefaultRowPrefetch(n)" method hoping that there might be something to do with that but with no success.
Any help will be much appreciated. Thank you.
GKK

Hello folks,
Here is what I've done:
1. Created a "mini" Realtional model (modelB) which mimics exactly our existing "big" Realtional model (modelA). The tables, sequences, indices, etc. in modelB have been created in exactly the same fashion we'd created the corresponding entities in modelA. The only difference is that I preceeded the entities in our test modelB with "TEST_".
2. Populated the modelB with 1298 Lakes (3993 edges in total) in exatly the same fashion we use to populate our modelA - using a Data Loader based on Java SDO API.
3. Indexed the test modelB in exactly the same fashion as modelA.
4. Ran the query:
SELECT e.shape FROM test_edge e WHERE SDO_RELATE(e.shape,
mdsys.sdo_geometry(
2003,
8307,
NULL,
mdsys.sdo_elem_info_array(1,1003,1),
mdsys.sdo_ordinate_array(
-123.80833332065798,48.58352678668598,
-123.80833332065798,48.675352618459506,
-123.65050767229724,48.675352618459506,
-123.65050767229724,48.58352678668598,
-123.80833332065798,48.58352678668598
), 'mask=ANYINTERACT querytype=WINDOW'
) = 'TRUE'
in SQL*PLUS and it worked fine (retrieved a bunch of geometries)!
Ran the same query in the Daniel Geringer's OraTest utility and it worked this time and returned:
TIME : 1.222 seconds, TOTAL FETCH TIME 267 ROWS
Ran the query with our JCS Query Plug-In and it worked fine!
ANALYSIS
========
ModelA
======
- 59652 Lakes and 178764 edges
- it's properly indexed
- its SDO layers and geometries are valid
- when we count the number of related SDO geometries for this query we get:
SQL> SELECT count(e.shape) FROM edge e WHERE SDO_RELATE(e.shape,
2 mdsys.sdo_geometry(
3 2003,
4 8307,
5 NULL,
6 mdsys.sdo_elem_info_array(1,1003,1),
7 mdsys.sdo_ordinate_array(
8 -123.80833332065798,48.58352678668598,
9 -123.80833332065798,48.675352618459506,
10 -123.65050767229724,48.675352618459506,
11 -123.65050767229724,48.58352678668598,
12 -123.80833332065798,48.58352678668598
13 )
14 ), 'mask=ANYINTERACT querytype=WINDOW'
15 ) = 'TRUE';
COUNT(E.SHAPE)
267
- when we run the following query via the Java SDO API:
SELECT e.shape FROM edge e WHERE SDO_RELATE(e.shape,
mdsys.sdo_geometry(
2003,
8307,
NULL,
mdsys.sdo_elem_info_array(1,1003,1),
mdsys.sdo_ordinate_array(
-123.80833332065798,48.58352678668598,
-123.80833332065798,48.675352618459506,
-123.65050767229724,48.675352618459506,
-123.65050767229724,48.58352678668598,
-123.80833332065798,48.58352678668598
), 'mask=ANYINTERACT querytype=WINDOW'
) = 'TRUE'
it FAILS with: "TNS end of communaction channel"!
ModelB
======
- 1298 Lakes and 3993 edges
- it's properly indexed
- its SDO layers and geometries are valid
- when we count the number of related SDO geometries for this query we get:
SQL> SELECT count(e.shape) FROM test_edge e WHERE SDO_RELATE(e.shape,
2 mdsys.sdo_geometry(
3 2003,
4 8307,
5 NULL,
6 mdsys.sdo_elem_info_array(1,1003,1),
7 mdsys.sdo_ordinate_array(
8 -123.80833332065798,48.58352678668598,
9 -123.80833332065798,48.675352618459506,
10 -123.65050767229724,48.675352618459506,
11 -123.65050767229724,48.58352678668598,
12 -123.80833332065798,48.58352678668598
13 )
14 ), 'mask=ANYINTERACT querytype=WINDOW'
15 ) = 'TRUE';
COUNT(E.SHAPE)
267
- when we run the following query via the Java SDO API:
SELECT e.shape FROM test_edge e WHERE SDO_RELATE(e.shape,
mdsys.sdo_geometry(
2003,
8307,
NULL,
mdsys.sdo_elem_info_array(1,1003,1),
mdsys.sdo_ordinate_array(
-123.80833332065798,48.58352678668598,
-123.80833332065798,48.675352618459506,
-123.65050767229724,48.675352618459506,
-123.65050767229724,48.58352678668598,
-123.80833332065798,48.58352678668598
), 'mask=ANYINTERACT querytype=WINDOW'
) = 'TRUE'
it SUCCESSFULLY returns the related geometries!
So, what can we make of all this? We know that there exists a model for which the SDO_RELATE works via the Java SDO API. This model is a subset (w.r.t. the data set) of our original model in which we detected the "TNS end of communication channel problem". The environment we used for these tests is exactly the same: JDBC Thin driver (version 9.0.1.0.0), Oracle9i Enterprise Edition (Release 9.0.1.2.1 - Production).
One can think that the problem lies in the Oracle Object-Realational or Oracle Spatial but the fact that we can successfully execute the same SDO_RELATE queries in SQL*PLUS rejects this possibility. Perhaps it depends on the amount of data passed to the JDBC driver and the fashion in which it handles it! In our test above we had RELATED 267 geometries. We know that there exist SDO_RELATE queries that run successfully with modelA, but those are queries which ONLY retrieve an EMPTY set of RELATED geometries. In other words we don't get the "TNS end of communication channel" because NO data gets fetched from the server to the client! As soon as we find a SDO_RELATE query which retrieves (RELATES) at least 1 geometry that runs successfully in SQL*PLUS and run it via the Java SDO API - it FAILS! This means that no matter what volume of data is fetched from the server-JDBCThin-SDOAPI-client as long as there is ANY data, the query FAILS in modelA.
Perhaps something internally in the Oracle 9i Server happens that prevent the data being fetch to the JDBCThin for that particular modelA. But what that might be?
Very peculiar problem!
Regards,
Georgi

JDBC Thin & NLS & Linux

I wrote Java application, which uses JDBC Thin 8.1.5 and runs on
Linux. When I inserts Russian text into table, JDBC inserts some
undefined (big black boxes in SQLPLUS output) characters. Output
from same table in my Java application seems to "???".
Oracle database (8.1.5 on RedHat 6.0) created in CL8KOI8R
charset.
All environment variables are valid:
NLS_LANG=RUSSIAN_CIS.CL8KOI8R
LC_ALL=ru_RU
CLASSPATH includes path to nls_charset11.zip
Russian works fine in SQLPLUS and Perl DBD::Oracle applications
on the same machine.
What I can do?
null

Have you tried more recent JDBC versions? Several NLS issues were fixed in post 8.1.5 JDBC releases (including, I believe, a problem with Hebrew). The JDBC folks would be able to give you more specific information about where which fixes appeared.
It should be worth a try, though, to check out a newer JDBC version, particularly if you are using the thin driver.

Does oracle 8.1.6.0 jdbc thin driver support jdk1.3 and oracle 8.0.5 database ?

I have downloaded oracle 8.1.6.0 jdbc thin driver(named classes12.zip) to run with jdk1.3 to access oracle 8.0.5, but when I compile and run the jdbccheckup.java downloaded from oracle website like this:
javac -classpath d:\jdbc\classes12.zip jdbccheckup.java
(compile succeed)
java -classpath d:\jdbc\classes12.zip jdbccheckup
an error occured:
Exception in thread "main" java.lang.NoClassDefFoundError:jdbccheckup
Why??????

Try this isntead.
java -classpath d:\jdbc\classes12.zip;. jdbccheckup
an error occured:
Exception in thread "main" java.lang.NoClassDefFoundError:jdbccheckup
Why??????

Local oracle access with jdbc thin

hello there
it need help despratly,
im developing an applet to talk to remote oracle dbs using jdbc
thin
but i also want an applet to be able to talk to a local oracle db
on the same hardisk.
for a remote connection the follwing stringis used at my
university
static final String connect_string =
"jdbc:oracle:thin:scott/[email protected]:1521:DSC1";
but what do i subsitute for thr host as i want to access the db
on my hard disk?
i need as much help ASP, as im well behind my schedule for this
project.?
also i take it that to allow this and access to remote servers
other than the web server, the applet needs to be signed, is this
possible with jdk1.1.x compatble browsers?
yours
richard sergio marchesi
email - [email protected]
or
email - [email protected]
null

The thin driver reqiures a TCP listener to be running. If you are
using Personal Oracle for the 'local' RDBMS then it doesn't have
a listener (with the default installation). Start the listener
and you should be able to connect. You will also want a local
webserver of some sort to serve the applet to you as well, but
anything (even TinyWeb) will do for that.
null

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

Changes to JDBC Thin URL (: vs /)

Since 10g, the JDBC Thin URLs have been documented to take the form jdbc:oracle:thin:scott/tiger@//myhost:1521/myservicename. However the old style URLs which uses : instead of / (for example jdbc:oracle:thin:scott/tiger@myhost:1521:myservicename) continues to work even in Oracle 11g.
Do we know if the support for the old style URLs will be taken off anytime so. There is no document suggesting this, but more & more examples and documentation seem to point towards the / style strings.
One exception case is when the target database is running under Real Application Cluster environment, where-in the old style URLs doesn't work.
Thanks for your help.
Alex

Welcome to the forum!
>
Since 10g, the JDBC Thin URLs have been documented to take the form jdbc:oracle:thin:scott/tiger@//myhost:1521/myservicename. However the old style URLs which uses : instead of / (for example jdbc:oracle:thin:scott/tiger@myhost:1521:myservicename) continues to work even in Oracle 11g.
>
What does 'continues to work even in Oracle 11g' mean? The URL syntax is specific to the JDBC driver jar version being used, not the version of the database.
>
Do we know if the support for the old style URLs will be taken off anytime so. There is no document suggesting this, but more & more examples and documentation seem to point towards the / style strings.
One exception case is when the target database is running under Real Application Cluster environment, where-in the old style URLs doesn't work.
>
No one but Oracle knows.
Oracle 9i was the last version to document the old-style syntax using a colon to separate the database name.
You should use the documented syntax for the version of the JDBC driver that is being used. As you noted since 10g that has been to use the forward slash.
It is also recommended to use DataSource. That class has 'setters' to set the properties (e.g. 'setDatabaseName') and the syntax issue doesn't even arise.
Sounds like you may already have read the 'Database URLs and Database Specifiers section of the JDBC Dev Guide but for others who haven't:
http://docs.oracle.com/cd/B28359_01/java.111/b31224/urls.htm#BEIJFHHB

JDBC Thin executeQuery ArrayIndexOutOfBoundsException

Similar Messages

Maybe you are looking for