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

Similar Messages

Sql_trace does not work for Java app using Oracle JDBC thin driver

Hi,
I'm using Oracle 8.1.7. I enabled sql trace at instance level by setting sql_trace and timed_statistics to true in init.ora. I restarted the db instance. I wrote a stand-alone java application which used Oracle JDBC thin driver(classes12.zip) to make a connection to my db instance, do some select statements, and close the connection. There were no trace files generated in the folder specified by udump_dest variable. However, if I used sqlplus or dba studio, I saw trace files generated. Has anyone got Oracle sql trace work for JDBC calls from java apps.
Thanks in advance!

Hi,
I'm using Oracle 8.1.7. I enabled sql trace at instance level by setting sql_trace and timed_statistics to true in init.ora. I restarted the db instance. I wrote a stand-alone java application which used Oracle JDBC thin driver(classes12.zip) to make a connection to my db instance, do some select statements, and close the connection. There were no trace files generated in the folder specified by udump_dest variable. However, if I used sqlplus or dba studio, I saw trace files generated. Has anyone got Oracle sql trace work for JDBC calls from java apps.
Thanks in advance!

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

Oracle JDBC Thin Driver and Firewall Problem

Hi!
We have Oracle 8.1.5 and Websphere App Server. There is a
firewall between the two. A servlet creates a connection pool
(not that of Wesphere's). The frontend is JSP/HTML (no applets).
The servlet uses the Oracle JDBC Thin Driver for DB Connections.
The problem is - Once the connection is freed, the connection
pool is not being able to retrieve it and hence it created
another one, thus reaching the max. # of connections and the
system hangs. Restarting the DB service flushes the connection
and the application starts running again...
There was a similar problem discussed in this forums long ago. I
have not yet tried mentioning the firwall port and IP in the
connection string. But apart from that, is there any other
setting I need to do (on firewall or for the connectionstring)
to deal with this problem?
Someone had suggested to punch a hole in the firewall for the DB
port - but we can not really do that in the current scenario...
I would appreciate if anyone could share their experience
regarding how they resolved this issue.
Thanks in advance,
Vijaya.

One more question -
Can we use Oracle JDBC OCI driver? We do not have any appletes...
Does it have firewall issues too? Is there any other driver that
we can use?
Thanks,
Vijaya.

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.

Change expired password using oracle jdbc thin driver

Hello,
I have a java program that uses the oracle jdbc thin driver (ojdbc6 - version 11.2.0.3) for database connection. My question is if I have any possibility to change an expired password (java.sql.SQLException: ORA-28001: the password has expired) using the thin driver - NOT OCI?

No - the thin driver doesn't have any password management features.

Connecting to OAS using Oracle JDBC Thin

Hi,
When I test connect to OAS residing on another host, using ORACLE JDBC THIN Driver and Named host method, I get the following error message :
"Got back minus one from a read call"
Any clues why such a message would come?
Thks
Sudha

If you are using the thin driver, sqlnet.ora does not come into play. None of Oracle networking does. That is one of the great things about using the thin driver, no need to have the client installed.
That error is due to incorrect connection info you are supplying or the machine you are connection from can't ping the machine it is trying to connect to.

Oracle JDBC Thin-Driver: Connection still valid (db still open)?

Hi,
I've got a problem with my program. The app opens a connection to an Oracle Database usingt the Oracle JDBC Thin.Driver. Everything works just fine but I can't figure out a way how to find out wheter the connection is still valid, e.g. if the database is still open?
connection.isClosed() return always false :(
Any help is appreciated.
Thanks,
Spaulding

Hi oracle_guru,
unfortunately it's not that easy. :(
You can't just check for
if(conn == null)since the connection won't realize when the db shuts down.
Therefore I created a connection-watcher-thread which uses a prepared statement to check every once in while if the connection is still valid.
Nevertheless, thanks for you reply,
Spaulding

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

Oracle JDBC Thin Driver for oracle 9.2.0.4

Hi,
It would be nice if someone please guide me to the download of Oracle JDBC Thin Driver for oracle 9.2.0.4.
Thanks in anticipation

user566773,
As far as I know, all Oracle JDBC drivers are meant to be backward compatible.
According to the table on the following Web page, the latest Oracle JDBC driver can be used with Oracle 9.2.0.x DBMS.
http://www.oracle.com/technology/tech/java/sqlj_jdbc/index.html
Good Luck,
Avi.

I think Oracle JDBC Thin driver has many problems

I developed application & applet using Oracle JDBC/Thin Drivers
for use with JDK 1.2 and SUN JDK 1.2.2.
In my computer, application runs correctly.
On the other hand, applet isn't run and throws error "Cannot
find class java/util/Map" on connecting to Oracle database.
You know, java/util/Map class is only in SUN JDK 1.2.x and
current web-browsers (for example, IE5.0, Netscape 4.7, ...)
don't support Java Run time 1.2.x.
I think this is very critial problem.
So I tried with Oracle JDBC/Thin Drivers for use with JDK 1.1.x
and SUN JDK 1.1.8. (Now SUN only supports JDK 1.1.8 in JDK 1.1.x
series)
But this time, applet throws error "Cannot find class javax/..."
You know, JDK 1.1.8 doesn't have javax/... classes but early JDK
1.1.x series had javax/.... classes.
May be Oracle JDBC/Thin Drivers for use with JDK 1.1.x are made
using these early JDK 1.1.x series, so I think Oracle JDBC/Thin
Drivers for use with JDK 1.1.x can't be used with SUN JDK 1.1.8.
Whatever is the matter!
null

You need to remote onto the server and go into start->control panel-Administration-> ODBC (or sometimes start->administration->ODBC) and set up ODBC connections . Make sure you set them up on the system tab, then you should see them in EAS. I don't remember, b ut don't think you need to restart the Essbase servise for them to take effect

Jdbc oracle jdbc-thin driver subname

I am working on Windows 2000 environment, using oracle8i 8.1.7 JDBC-Thin driver for use with JDK 1.2.x. The oralce8i 8.1.7 database is on another linux box. I can access the linux box through its ip address, but not by its hostname since it's not accessiable by the dns server. In my code, in the JDBCUrl, I used ip address instead of the hostname, e.g. "jdbc:oracle:thin:@10.0.113.108:1521:ora1". But I got the error like: "java.sql.SQLException: Io exception: The Network Adapter could not establish the connection". If I add a entry in my working machine's hosts file to map the hostname, I can fix the problem. But I don't know if this is the solution, or there is other better solutions.
Thanks
null

Using a hosts file entry is a common solution for problem where the dns lookup does not contain an entry for a RDBMS server platform.
The real solution is to resolve this issue :
"where the dns lookup does not contain an entry for a RDBMS server platform."

Oracle JDBC thin driver 10g exceptions

Can anyone tell me where I can find more resources about exceptions what I should expect if one node in cluster fails.
Let assume that I am using WebLogic server.
Thanks,

We had a major problem in which we tried to roll the
web app over to running against an Oracle database,
and the number of open connections in our pooling
code (that worked fine with the old database) blew up
when lots of users started getting onto the site.
The connections just were not being released, That statement is non-sensical.
By definition the only point of a connection pool is to NOT release connections.
and any JDBC calls starting spitting out exceptions,
and the Oracle 10g thin client driver was saying that
the maximum number of sessions were open (we were in
the hundreds--we have a per-CPU license, so that
shouldn't be an issue).
We're not sure what to test right now. Whether we
use Statements or PreparedStatements, we try to
always close the Statement (which should close the
ResultSet, if there is one) and then in the finally
part of our try-catch-finally, we try to close the
connection. Is that all we need to do? You must always close the result set first.
Then you must always close the statement.
Then you need to return the connection to the pool - explicitly. Usually, these days, that is done by calling the close method. It is certainly possible that your pool uses another method though.
Can you
think of anything we should be looking for?It is possible you have connection pool mis-configured as well.

Oracle JDBC Thin Driver

I am using CLOBS with the Oracle thin driver and am experiencing horrible performance. We need datavalues more than a VARCHAR2 and have used CLOB but the method Oracle uses to get the data in and out is super slow.
MS SQL Server JDBC with text is awesome and fast. But Oracle is slow and very cumbersome.
Help

We are using 9.0.2.
So what you are saying is although the column is CLOB
in Oracle 10 g we can use a normal result set
rset.getString( 1 ) no special oracle stuff just the
e Oracle thin driver for 10g?
Also this will retrieve a String greater than 4000
bytes?Exactly. Not only you can retieve a clob as string, you can also insert clob
as a string too. Here is the code I referred in last post in case you do not
have access to oracle ten network:
* @author Savitha
* @version 1.0
* Development Environment : Oracle JDeveloper 10g
* Name of the Application : ClobManipulationIn10g.java
* Creation/Modification History :
* Savitha 17-Mar-2004 Created.
package oracle.otnsamples.jdbc;
// Java SQL classes
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.Statement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;
// Oracle JDBC driver class
import oracle.jdbc.OracleDriver;
// Java IO classes
import java.io.IOException;
import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
//Java Util classes
import java.util.Properties;
* This class demonstrates the Oracle JDBC 10g enhanced features for inserting
* and retrieving CLOB data from the database. Using the new features, large
* data of more than 32765 bytes can be inserted into the database using the
* existing PreparedStatement.setString() and PreparedStatement.getString()
* methods.
public class ClobManipulationIn10g {
/* Database Connection object */
private Connection conn = null;
/* Variables to hold database details */
private String url = null;
private String user = null;
private String password = null;
// Create a property object to hold the username, password and
// the new property SetBigStringTryClob.
private Properties props = new Properties();
/* String to hold file name */
private String fileName = null;
* Default Constructor to instantiate and get a handle to class methods
* and variables.
public ClobManipulationIn10g(String fileName) {
this.fileName = fileName;
* Main runnable class.
public static void main(String[] args) throws SQLException {
// Instantiate the main class.
ClobManipulationIn10g clobManipulationIn10g =
new ClobManipulationIn10g(args[0]);
// Load the Oracle JDBC driver class.
DriverManager.registerDriver(new OracleDriver());
// Load the database details into the variables.
String dbUrl = "jdbc:oracle:thin:@<database host machine>:<port>:<SID>";
clobManipulationIn10g.url = dbUrl;
// Replace the username where the table 'clob_tab' was created.
clobManipulationIn10g.user = "scott";
// Replace the password of the username.
clobManipulationIn10g.password = "tiger";
// Populate the property object to hold the username, password and
// the new property 'SetBigStringTryClob' which is set to true. Setting
// this property allows inserting of large data using the existing
// setString() method, to a CLOB column in the database.
clobManipulationIn10g.props.put("user", clobManipulationIn10g.user );
clobManipulationIn10g.props.put("password", clobManipulationIn10g.password);
clobManipulationIn10g.props.put("SetBigStringTryClob", "true");
// Check if the table 'CLOB_TAB' is present in the database.
clobManipulationIn10g.checkTables();
// Call the methods to insert and select CLOB from the database.
clobManipulationIn10g.insertClob();
clobManipulationIn10g.selectClob();
* This method will insert the data into a CLOB column in the database.
* Oracle JDBC 10g has enhanced the existing PreparedStatement.setString()
* method for setting the data more than 32765 bytes. So, using setString(),
* it is now easy to insert CLOB data into the database directly.
private void insertClob() throws SQLException {
// Create a PreparedStatement object.
PreparedStatement pstmt = null;
try {
// Create the database connection, if it is closed.
if ((conn==null)||conn.isClosed()){
// Connect to the database.
conn = DriverManager.getConnection( this.url, this.props );
// Create SQL query to insert data into the CLOB column in the database.
String sql = "INSERT INTO clob_tab VALUES(?)";
// Read a big file(larger than 32765 bytes)
String str = this.readFile();
// Create the OraclePreparedStatement object
pstmt = conn.prepareStatement(sql);
// Use the same setString() method which is enhanced to insert
// the CLOB data. The string data is automatically transformed into a
// clob and inserted into the database column. Make sure that the
// Connection property - 'SetBigStringTryClob' is set to true for
// the insert to happen.
pstmt.setString(1,str);
// Execute the PreparedStatement
pstmt.executeUpdate();
} catch (SQLException sqlex) {
// Catch Exceptions and display messages accordingly.
System.out.println("SQLException while connecting and inserting into " +
"the database table: " + sqlex.toString());
} catch (Exception ex) {
System.out.println("Exception while connecting and inserting into the" +
" database table: " + ex.toString());
} finally {
// Close the Statement and the connection objects.
if (pstmt!=null) pstmt.close();
if (conn!=null) conn.close();
* This method reads the CLOB data from the database by using getString()
* method.
private void selectClob() throws SQLException {
// Create a PreparedStatement object
PreparedStatement pstmt = null;
// Create a ResultSet to hold the records retrieved.
ResultSet rset = null;
try {
// Create the database connection, if it is closed.
if ((conn==null)||conn.isClosed()){
// Connect to the database.
conn = DriverManager.getConnection( this.url, this.props );
// Create SQL query statement to retrieve records having CLOB data from
// the database.
String sqlCall = "SELECT clob_col FROM clob_tab";
pstmt= conn.prepareStatement(sqlCall);
// Execute the PrepareStatement
rset = pstmt.executeQuery();
String clobVal = null;
// Get the CLOB value from the resultset
while (rset.next()) {
clobVal = rset.getString(1);
System.out.println("CLOB length: "+clobVal.length());
} catch (SQLException sqlex) {
// Catch Exceptions and display messages accordingly.
System.out.println("SQLException while connecting and querying the " +
"database table: " + sqlex.toString());
} catch (Exception ex) {
System.out.println("Exception while connecting and querying the " +
"database table: " + ex.toString());
} finally {
// Close the resultset, statement and the connection objects.
if (rset !=null) rset.close();
if (pstmt!=null) pstmt.close();
if (conn!=null) conn.close();
* Method to check if the table ('CLOB_TAB') exists in the database; if not
* then it is created.
* Table Name: CLOB_TAB
* Column Name Type
* col_col CLOB
private void checkTables() {
Statement stmt = null;
ResultSet rset = null;
try {
// Create the database connection, if it is closed.
if ((conn==null)||conn.isClosed()){
// Connect to the database.
conn = DriverManager.getConnection( this.url, this.props );
// Create Statement object
stmt = conn.createStatement();
// Check if the table is present
rset = stmt.executeQuery(" SELECT table_name FROM user_tables "+
" WHERE table_name = 'CLOB_TAB' ");
// If the table is not present, then create the table.
if (!rset.next()) {
// Table does not exist, create it
stmt.executeUpdate(" CREATE TABLE clob_tab(clob_col CLOB)");
} catch (SQLException sqlEx) {
System.out.println("Could not create table clob_tab : "
+sqlEx.toString());
} finally {
try {
if( rset != null ) rset.close();
if( stmt != null ) stmt.close();
if (conn!=null) conn.close();
} catch(SQLException ex) {
System.out.println("Could not close objects in checkTables method : "
+ex.toString());
* This method reads the specified text file and, returns the content
* as a string.
private String readFile()
throws FileNotFoundException, IOException{
// Read the file whose content has to be passed as String
BufferedReader br = new BufferedReader(new FileReader(fileName));
String nextLine = "";
StringBuffer sb = new StringBuffer();
while ((nextLine = br.readLine()) != null) {
sb.append(nextLine);
// Convert the content into to a string
String clobData = sb.toString();
// Return the data.
return clobData;
}

ORACLE JDBC Thin 8.0.x - NOT Y2K compliant?

Similar Messages

Maybe you are looking for