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

Similar Messages

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.

EXTPROC_CONNECTION_DATA from JDBC thin

I'm trying to connect to a database which uses external procedure libraries for some of it's PL/SQL functions. The documentation for the library mentions adding the following to the tnsnames.ora file. Is there a way using the Oracle JDBC thin driver to specify this same information for a JDBC URL without requiring a tnsnames.ora file?
EXTPROC_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = extproc))
(CONNECT_DATA =
(SID = PLSExtProc)
Thanks,
Paul

The DBA had not configured the server correctly. When that was done there was no change required on the client.

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?

Using JDBC-thin driver

Hello,
I am using CMSDK on a propretary software, after the upgrade to version 9.0.3, it seems that the API uses by default the OCI driver and it looks for the db url from the domain url when starting the IFS service.
The problem with that is the JDBC-OCI driver character encoding of utf-8 charaters in C which transforms the characters in an unwanted form (I use arabic characters in input and get garbage stored in the database).
Is there a way to make CMSDK uses the jdbc-thin driver instead of jdbc-oci driver?
I hope so, and I would like to know how to do it.
Thanks in advance.
Amin AZZI
AAcom AlgÃ©rie.
Algiers/Algeria

Hello everybody,
I could finally use the JDBC-THIN driver by directly changing the IFS.SERVICE.JDBC.DriverType property in the database repository to thin (by default it is oci8).
Since there are three different services configurations someone must change the correct one.
Amine.

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

Error Code Definition for JDBC Thin driver

Would like to know where I can find the definition of error codes
for JDBC thin driver to Oracle 7 database. Right now, when I have
database errors, I get SQL execption with CODE=XXXXXX. Need to
know the definition of the error codes in order to decide whether
the application shall retry or quit or do something else. Thank
you in advance.
null

Hi,
thin client session Language is controlled by java Locale.
Based on testing code, ORA- messages are localized after the connection is successfully established. ORA- messages returned in the middle of connecting are in instance language.
So, as far as I can say, you need to catch exceptions from DriverManager.getConnection(url, info); and translate them on your own.
Once the connection is successfully returned, ORA- message language is defined by java Locale.
Tests were performed on Oracle 10gR2 (both thin driver and DB).

Oracle: Please implement simple performance improvement in JDBC (Thin) Driver

Oracle should put dynamic prefetch into their (thin) JDBC driver. I don't use the OCI driver so I don't know how this applies.
Some of you may be aware that tweaking a statement's row prefetch size can improve performance quite a lot. IIRC, the default prefetch is about 30 and that's pretty useless for queries returning large (# of rows) resultsets, but it's pretty good for queries returning only a small number of records. Just as an example, when running a simple SELECT * FROM foo WHERE ROWNUM <= somenumber query, here's what I got:
Prefetch = 1: 10000 rows = 15 secs, 1000 rows = 1.5 secs, 10 rows = 30 ms
Prefetch = 500: 10000 rows = 2.5 secs, 1000 rows = 280 ms, 10 rows = 80 ms
Prefetch = 2000: 10000 rows = 2 secs, 1000 rows = 700 ms, 10 rows = 460 ms
From our experience, the default of 30 (?) is too low for most applications, 500 to 1000 would be a better default. In the end, though, the only way to get best performance is to adjust the prefetch size to the expected number of rows for every query. While that sounds like a reasonable effort for developers of a simple client/server application, in a 3-tier system that deals with connection pools in an application server, this just won't work, so here's my suggestion on how Oracle should address this:
Instead of having just a single prefetch setting for the statement (or connection), there should be an 'initial' prefetch value (with a default of somewhere between 1 and 50) and a maximum prefetch value (with a default of somewhere between 500 and 5000). When the driver pulls the first batch of records from the server it should use the initial refresh. If there are more records to fetch, it should fetch them using the maximum prefetch. This would allow the driver to perform much better for small AND large resultsets while, at the same time, making it transparent to the application (and application developer).
[email protected]

I have exactly the same problem, I tried to find out what is going on, changed several JDBC Drivers on AIX, but no hope, I also have ran the process on my laptop which produced a better and faster performance.
Therefore I made a special solution ( not practical) by creating flat files and defining the data as an external table, the oracle will read the data in those files as they were data inside a table, this gave me very fast insertion into the database, but still I am looking for an answer for your question here. Using Oracle on AIX machine is a normal business process followed by a lot of companies and there must be a solution for this.

ADF panel opening too many JDBC Thin Client database sessions.

Hi All,
I have several ADF Panels, which allows the user to run a few simple queries against an Oracle database done using ADF view objects and ADF view links and ADF application module.
Each ADF panel as I said contains several View Link queries, and links under the form of Jbuttons to other ADF Panels running other ADF View Links.
Running the ADF Panel as described here opens up to 21 database sessions displaying as “JDBC Thin Client” when I look them up from v$session.
Why do I end up with that many database sessions.
Why doesn’t it just use one or two database sessions to run all these View Links? It seems that it is opening one database session for each of these view links.
How can I change this destructive behavior? I only one to see one or two database sessions for the entire ADF panel no matter how many ADF View Links it contains.
Your suggestions are most appreciated.
Thanks.
Bobby A.

Thanks for your response.
I took a quick look at the docs you pointed me to. It seems that I can set some parameters in bc4j.xcfg of each application module Home to control number of database connections that the application module will create. In that case maybe you can recommend which parameters and what value they should be set to.
Your response will be most helpful as my background is rather in database admin and not java.
Thanks.
Bobby A.

Connection through jdbc thin client taking more time than from sqlplus!!!

Hello All
Machines A and B
Applicaion in A is connecting to B(9.2.0.6),db server.
The schema is so small with few tables and data in each table less than 500 rows
We are in the process of migrating the Application Schema in B to C[9.2.0.8].
But the response time is more when the application fetches from C.
Even while selecting the sysdate from dual.
The application is using the jdbc thin client for fetching the data.
When the same sql is executed by (from A to C)
sqlplus -s user/pass @execute.sql, its gets done in a fraction of a second.
But when the same is done through the application which uses jdbc thin client, it takes few seconds
to complete.
When tried with a small java program that uses classes12.jar (from A to C)
conn = DriverManager.getConnection(URL,UID,PASS);
               stop = System.currentTimeMillis();
               System.out.println("Connection time in milli sec: " + (stop - start));
               System.out.println();
..It was found that creating the connection was taking time.
But the same is not happening when tired through the sqlplus
Could someone throw some light into this?
What could be the reason for jdbc to get slower while establishing connections?
TIA,
JJ

are you using latest drivers - http://www.oracle.com/technology/tech/java/sqlj_jdbc/index.html
you may want to check some options reducing jdbc connection cost from the otn samples - http://www.oracle.com/technology/sample_code/tech/java/sqlj_jdbc/index.html

JDBC Thin driver connection

Hi,
I am trying to open a connection from Java using JDK 1.1.6 and the Oracle JDBC Thin drivers. My Oracle drivers register just fine. However, I get an exception which I catch saying "Security.couldn't connect to HOST with origin from." HOST is my local server name where I'm running Oracle 8.0.4.0.0 and OAS 4.0.8. My connection statement in my .java code is:
Connecttion conn =
DriverManager.getConnection("jdbc:oracle:thin@HOST:1521:orcl,"scott","tiger")
I can connect just fine using sqlplus with the scott/tiger@orcl descriptor.
How can I resolve this?

<BLOCKQUOTE>quote:<HR>Originally posted by JDBC Development Team:
Not sure whether this is the cause of the problem. There should be a ":" before the "@" sign in the connect string. That is,
"jdbc:oracle:thin:@host"
Please do let us know if this doesn't fix the problem
<HR></BLOCKQUOTE>
Thank you for pointing out the missing : before the @ symbol. I made that change. Still, I get the same message when the applet loads in my browser page. If I load the applet in appletviewer then I get the error message "checkconnect.networkhost1".

JDBC Thin Drivers

Hi,
I have downloaded Oracle thin drivers for jdk1.2.2 from oracle's site. But when i tried to hit the Database with it iam getting "Network Adapter error". I ahd given the url correctly. I checked up the application by running on the system where oracle is installed and it is running perfectly but when i access the database by installing thin drivers on some other machine and testing it, iam not able to connect to database. Iam getting Network adapter error and i also checked up with the network people and the assured me that there are no network problems as i am able to oracle server by pinging and thru telnet also. Any help will be greatly appreciated and Thanx in Advance.

Marcelo,
You can download JDBC 2.0 - friendly drivers from Openlink
Software (http://www.openlinksw.com). Our latest 3.2 versions
that support JDK 1.2 can be found at
ftp://ftp.openlinksw.com/pre-3.2/index.html
... if you scroll to the NT / 95 section at the bottom of the
page, you'll find the "opljdbc2.jar" in the list.
Best regards,
Stephen
Marcelo Malagutti (guest) wrote:
: Hello.
: I3d like to know when will be released the JDBC thin drivers
for
: Oracle 8.0.4, compatible with the JDK 1.2. I need it to use
the
: new Java BLOB features of the JDK 1.2. Thanks.
null

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

OS_USER not correct when using JDBC Thin Client on 10G

Hi Folks,
We are migrating an application from a 9i database to 10g and have a problem that someone might have come across before.
The application is a Java applet based application that connects to the database using JDBC Thin client. on 9i the OS_USER comes up as the user running the applet but in 10G it is coming up as the user account that installed 10G on the DB server.
We tried using a 9i client to identify if it was a client or DB issue but its the same problem with the 9i client connecting to the 10G DB.
If anyone can help it would be much appreciated.
Thanks,
John.

Could you please provide further details on what do you mean with OS_USER?
The application is a Java applet based application
that connects to the database using JDBC Thin client.
on 9i the OS_USER comes up as the user running the
applet but in 10G it is coming up as the user account
that installed 10G on the DB server.
Are you referring to the user provided to perform authentication against database, i.e. a database user?
How do you know this user is being changed?
~ Madrid

Changes to JDBC Thin URL (: vs /)

Similar Messages

Maybe you are looking for