Oracle 10g JDBC question

[waynes_zhong]

Hi,

I am currently using oracle/jdbc/lib/classes12.zip to connect to
Oracle8i:

String driver="oracle.jdbc.driver.OracleDriver";
String url="jdbcracle:thinserverName:1521:dbName";
String username="myOracleUsername";
String password="myOraclePassword";

(Setting: JDK1.4; Tomcat4)

Now, if the db is upgraded to 10g, what do I expect in terms of jdbc
driver settings?

Thanks,

Wayne

 

[Igor Kolomiyets]

No changes necessary. I think it would even work with the same driver
but it is a wise thing to do to use new driver bundled with the 10g client.

(e-mail address removed) пишет:

 

[Malte]

Hi,

I am currently using oracle/jdbc/lib/classes12.zip to connect to
Oracle8i:

String driver="oracle.jdbc.driver.OracleDriver";
String url="jdbcracle:thinserverName:1521:dbName";
String username="myOracleUsername";
String password="myOraclePassword";

(Setting: JDK1.4; Tomcat4)

Now, if the db is upgraded to 10g, what do I expect in terms of jdbc
driver settings?

Thanks,

Wayne

I use a connection String like yours for 9i and 10G without any changes
necessary (for the thin driver).

 

[Dimitri Maziuk]

(e-mail address removed) sez:

Hi,

I am currently using oracle/jdbc/lib/classes12.zip to connect to
Oracle8i:

String driver="oracle.jdbc.driver.OracleDriver";
String url="jdbcracle:thinserverName:1521:dbName";
String username="myOracleUsername";
String password="myOraclePassword";

(Setting: JDK1.4; Tomcat4)

Now, if the db is upgraded to 10g, what do I expect in terms of jdbc
driver settings?

Old driver may not work. I forget what the error message was,
something to do with NLS charset. (Happens on some systems and
update 3 of 10g.)

New dirver is oracle.jdbc.OracleDriver. The one with .driver.
is still supported for backwards compatibility but all new
features go into the new one.

Dima

 

[steve]

Hi,

I am currently using oracle/jdbc/lib/classes12.zip to connect to
Oracle8i:

String driver="oracle.jdbc.driver.OracleDriver";
String url="jdbcracle:thinserverName:1521:dbName";
String username="myOracleUsername";
String password="myOraclePassword";

(Setting: JDK1.4; Tomcat4)

Now, if the db is upgraded to 10g, what do I expect in terms of jdbc
driver settings?

Thanks,

Wayne

your drivers are out of date, you should be using atleast ocrs12.zip
,ojdbc14.jar.

settings should be the same, I.E it works for me when i went from 8i to 9i
to 10G

 

[.]

Hi,

I am currently using oracle/jdbc/lib/classes12.zip to connect to
Oracle8i:

String driver="oracle.jdbc.driver.OracleDriver";
String url="jdbcracle:thinserverName:1521:dbName";
String username="myOracleUsername";
String password="myOraclePassword";

(Setting: JDK1.4; Tomcat4)

Now, if the db is upgraded to 10g, what do I expect in terms of jdbc
driver settings?

If you switch to 10g you should switch to the drivers in ojdbc14.jar.
There will be no changes to your code.

NOTE: you can continue to use the classes12.zip but many things will not
work. It is not JDBC 3.0 compliant. The driver in ojdbc14.jar is up to
date and supports JDBC 3.0 APIs.

 

[Dave Ockwell-Jenner]

Hi,

I am currently using oracle/jdbc/lib/classes12.zip to connect to
Oracle8i:

String driver="oracle.jdbc.driver.OracleDriver";
String url="jdbcracle:thinserverName:1521:dbName";
String username="myOracleUsername";
String password="myOraclePassword";

(Setting: JDK1.4; Tomcat4)

Now, if the db is upgraded to 10g, what do I expect in terms of jdbc
driver settings?

You should also be careful if you intend on working with DATE columns...
have a look at:

http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm#08_01

.... which explains the situation nicely!

 

[Joe Weinstein]

You should also be careful if you intend on working with DATE columns...
have a look at:

http://www.oracle.com/technology/tech/java/sqlj_jdbc/htdocs/jdbc_faq.htm#08_01


... which explains the situation nicely!

Yep. I went around and round with them over this. Oracle misinterpreted
the JDBC spec when they changed the mapping of their DATE column to a
java Date object. Their enforcing correspondence of these column type
*names* is petty and pointless. The names of columns bear no semantic
relation or specified tie to Java or JDBC types. Oracle should clearly
map both their DATE and TIMESTAMP columns to a java.sql.Timestamp because
the semantics of both those columns have that meaning. What if Oracle
invented a new decimal column that had higher precision than their current
NUMBER column? Would they feel compelled to change their mapping of NUMBER
to BIGINTEGER and lose all the sub-unit precision?
Joe Weinstein at BEA

 

[Dimitri Maziuk]

Joe Weinstein sez:

.... What if Oracle
invented a new decimal column that had higher precision than their current
NUMBER column? Would they feel compelled to change their mapping of NUMBER
to BIGINTEGER and lose all the sub-unit precision?

They map to BIGINTEGER now? Last time I tried

switch( ResultSetMetaData.getColumnType( i ) ) {
case java.sql.Types.INTEGER : ...
case java.sql.Types.FLOAT : ...
}

I ended up with no numbers in the table -- they mapped everything
to NUMERIC.

Dima

 

[Joe Weinstein]

Joe Weinstein sez:

... What if Oracle



They map to BIGINTEGER now? Last time I tried

switch( ResultSetMetaData.getColumnType( i ) ) {
case java.sql.Types.INTEGER : ...
case java.sql.Types.FLOAT : ...
}

I ended up with no numbers in the table -- they mapped everything
to NUMERIC.

Right, no they don't. That's the point. No matter how many column types they
have that semantically map to a given java.sql type, they should map them all
to that type. Both their DATE and new TIMESTAMP columns store the date and time,
so the driver should return a java.sql.Timestamp if I do a getObject() on either
column, but by default (by fault imo) the 10g driver returns a java.sql.Date
now for an oracle DATE column, so you lose the time component of your data!
Joe

 

[steve]

Yep. I went around and round with them over this. Oracle misinterpreted
the JDBC spec when they changed the mapping of their DATE column to a
java Date object. Their enforcing correspondence of these column type
*names* is petty and pointless. The names of columns bear no semantic
relation or specified tie to Java or JDBC types. Oracle should clearly
map both their DATE and TIMESTAMP columns to a java.sql.Timestamp because
the semantics of both those columns have that meaning. What if Oracle
invented a new decimal column that had higher precision than their current
NUMBER column? Would they feel compelled to change their mapping of NUMBER
to BIGINTEGER and lose all the sub-unit precision?
Joe Weinstein at BEA

yep the oracle advice if fucking shit.

Alter you application to use getTimestamp rather than getObject. This is a
good solution when possible, however many applications contain generic code
that relies on getObject, so it isn't always possible.


yep like when i loop round a resultset getting objects, now i have to stick
in If statments to test if it is a "date" and branch to a "getTimestamp",
not to mention all the extra code in a "custom table model" to display and
the code needed to reformat dates to put them back into the database. ( no
direct routines available to convert to and from the different formats!!)