Bug 585844 JDBC Thin and Char Fields

I would like to see this bug fixed because the workaround that I
have been using for the past two years is a cluge. I could buy
the reasoning listed in the bug database at to why why this bug
exists, and why it hasn't been fixed, except that it doesn't
exist in the OCI driver. Please make the drivers consistant.
The JDBC API does not provide a way to differentiate
CHARS from VARCHAR2. When setString is used we have chosen to map
it
to a VARCHAR2, and as a consequence the blank-padded and
non-padded
comparison semantics for CHARs don't work.
Since this is an API restriction, we can't easily fix it. What
can be
done to fix it, is to add an Oracle Extension like
setChar(1,"one")
in which case JDBC will know that this type is s CHAR instead of
a VARCHAR2
and the comparison semantics will work. I believe that since this
a JDBC
restriction, it should be treated as an enhancement request.
null

The OCI would hanlde this sort of thing for you (translating the
char types) which is probably why it works in that driver. The
thin driver is just using java sockets to transport SQL and there
is no underlying client layer support.
null

Similar Messages

JDBC thin and thick clients

What is the difference between JDBC thin and JDBC thick clients and their usage ?

hi,
in sort tearms,
Oracle has a thin client driver which mean you can connect to a oracle database without the Oracle client installed on your machine.
Thick client would need the Oracle Client database drivers etc.. Drivers include JDBC-ODBC bridge drivers JDBC drivers depending on tns resolution.
thanks

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

JDBC Thin and Oracle 7.3.4

Hi again.
Thanks for your previous answer concerning
the connection between JDeveloper and OAS to the Oracle 7.3.4 database.
I am now trying to establish a connection with the database from JDeveloper using the JDBC Thin Driver. I pinged the database from a DOS window and all went OK. I haven't installed SQL*Net, because as I understood that wouldn't be necessary, or?
When I try to create a new connection in JDeveloper to the database and test it, i get this reply in a little window:
Connection Refused(DESCRIPTION=(TMP=)(VSNNUM=36716544)(ERR=12505)(ERROR_STACK=(ERROR=(CODE=12505)(EMFI=4))))
I've entered the correct IP in the host name and the port is the default 1521 with SID=ORCL. I also entered a username and password that are valid.
These errorcodes don't say anything to me, maybe you understand them, or maybe it's a simple error...
Hope you can help me,
Thanks in advance,
/Janne ([email protected])

Ignore this message, I found out for myself.
The database didn't use the default SID... ;)
null

JDBC Thin and OPS

Looking to see if anyone has attempted jdbc thin connections to a multi node OPS. Specifically, is there a way to automate failover of the connections when the OPS switches primary nodes?

I also have the same problem.It is possible jdbc thin connections to a multi node OPS?And how if possible?
Thankx advance!

Possible bug? Nested tables and quantity fields in the nested table.

Hey guys,
I have witnessed a weird bug, maybe someone can clarify this for me.
1. Create a nested table. The inner table contains a quantity field of type DZIEME (FROM VBAP-ZIEME).
2. Create your interface and just put this table in the import section. Try to activate. It will work.
3. Create an adobe form for it and a program and execute it. You'll get a short dump saying that VBAP-ZIEME is unknown and that there are errors in the dynamically generated function.
Second test.
1. Create a nested table. The outer table contains a quantity field of type DZIEME (FROM VBAP-ZIEME).
2. Create your interface and just put this table in the import section. Try to activate. It will NOT work.
You have to make the addition of the quantity fields in Currency/Quantity Fields.
From this I see that the checker, doesn't look into nested tables for quantity/currency fields and just activates the interface.
Third test
1. Create a nested table. The inner table contains a quantity field of type DZIEME (FROM VBAP-ZIEME).
2. Create your interface:
2.a. Put this table in the import section.
2.b. Declare the nested Quantity field in the Currency/Quantity Fields section, using the autofiller (the buttons to the right of the field)
2.c Try to activate. It will work.
3. Create an adobe form for it and a program and execute it. You'll get a short dump which for some reason has no info.
From this, I understand that the Currency/Quantity Fields section may not declare the quantity fields, from nested tables, correctly.
What do you guys think? What am I doing wrong?
Thanks,

@Anne Kathrine P...
By nested tables I mean creating table types, in the dictionary (se11) then in the interface>Import section adding a parameter X TYPE B_T.
i.e.
Structure A
Table type of structure A, A_T
Structure B containing a field of table type A
Table type B of structure B, B_T.
The issue can be easily solved for Z tables by changing the component type from quantity to decimal type.

JDBC Thin vs Thick Driver

Hello,
We are looking for differences between Oracle JDBC Thin and OCI (thick) driver with respect to
1. Peformance of the Java application.
2. Maintenance and administration
3. Known issues with OCI (thick) driver which is handled by Thin or vice versa.
4. Better security
Appreciate any help on the above.
Thanks and Regards,
Vamsi Mohan Harish

1. Performance of the Java application.
The difference in driver implementation is likely to be trivial compared to other considerations (network round trip time, application design, etc). However if you are really interested then chapter 19 of 'Java Programming with Oracle JDBC' by Donald Bales (O'Reilly) has some good information on this topic. It also happens to be available online: http://www.onjava.com/pub/a/onjava/excerpt/oraclejdbc_19/index.html
Keep in mind that it is a little out of date now - you should run tests using the current versions of the drivers.
2. Maintenance and administration
The JDBC Thin driver is typically easier to update/distribute, as installation consists of copying a .jar file or two. The only case where OCI has an advantage is in the use of Oracle's naming layer for database service abstraction. Of course this assumes the database server is listening for TCP/IP and not the legacy protocols that are only supported by OCI. Failover configurations using TAF are supported by OCI only. The newer 'Fast Connection Failover' feature of 10g RAC can also run over Thin though.
3. Known issues with OCI (thick) driver which is handled by Thin or vice versa.
In my experience each has a roughly equal number of bugs. I find it easier to track them down in the Thin driver though :-)
4. Better security
The security options for the Thin driver are more limited with regard to external authentication and support for some of the Oracle Advanced Security features. However, both support the basics like encrypted connections. Chapter 23 of the JDBC driver docs goes into more depth: http://download-west.oracle.com/docs/cd/B14117_01/java.101/b10979/toc.htm
Hope this helps.
Jonathan.

JDBC Thin connection

When use Jdev30 to connect to Oracle803 server, I got error message "End of TNS Data Channel".
I select Oracle JDBC Thin and Named Host in the Connection Wizard.
Please help me.

Sorry, forgot to add that you should probably check the Oracle 8i JDBC User's Guide and reference for more information. The JDBC Technologies page on OTN may also have some additional information.
The JDBC doc includes some sample code for testing your connection through JDBC code rather than through Jdeveloper. That is your best first line of defense.
Laura

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

JDBC thin driver pads CHAR col to byte size when NLS_LENGTH_SEMANTICS=CHAR

We're using an Oracle 9.2 database with the database character set specified as AL32UTF8 with NLS_LENGTH_SEMANTICS set to CHAR. I've reproduced this problem with both the "classes12.zip" and "ojdbc14.jar" available with the Oracle 9.2 client installation.
The problem occurs with the JDBC thin driver. The problem does not occur with the JDBC OCI driver (nor SQL*Plus 9.2).
There are 2 relatively simply workarounds: use the OCI driver or convert CHAR columns to VARCHAR2 columns. I'm mostly curious as to whether there is some kind of setting for the thin driver to circumvent this problem, or if this is actually expected behavior. We're not that familiar with the NLS_LENGTH_SEMANTICS setting.
Consider a table as follows:
create table my_table (status CHAR(1));
If I describe the table it correctly shows the column using CHAR semantics.
STATUS CHAR(1 CHAR)
Given the AL32UTF8, this means that 4 bytes of storage are reserved for this column.
If I insert a single ASCII character in this table (for example "A") then read it back using the JDBC thin driver, I get the string "A " - the letter A followed by 3 spaces. In other words, the thin driver appears to have padded the value to its BYTE length. The OCI driver and SQL*Plus do not pad the value.
I understand that CHAR columns are normally blank padded when the data size is shorter than the defined column length, but I think that with NLS_LENGTH_SEMANTICS=CHAR, the padding should be based on the length of the column in chars, not in bytes.
Can anyone shed some light on this issue?
Thanks in advance,
Tim

Update:
I guess I should mention we're using Java 2 SDK 1.4.1_01 on Windows XP with an Oracle 9.2 database on Windows 2000.

Bad data returned using DSEE6.3: JDBC Data View to DB2 for CHAR fields

I have created a JDBC dataview to a DB2 database using com.ibm.as400.access.AS400JDBCDriver. When using ldapsearch, the data returned is inconsistent with that which is on the database. The DB2 table has data types of CHAR, DECIMAL, and NUMERIC. For the Decimal and Numeric fields, I am not experiencing a problem. The data returned here maps exactly to that which is on the table. For CHAR fields, I get mixed results.
When defining JDBC attributes in DSEE, I mapped the sql-syntax attribute accordingly for each corresponding attribute on the DB2 table. As a side note, I also configured each attribute so the ldap-syntax = ces (Case sensitive). Also, I could not find a way to define the length of the char for my JDBC attribute. I'm not sure if there's supposed to be a way that I just haven't figured out yet.
For the CHAR fields, in some cases I get what's on the data source. In other cases, I don't. I've tried to find a pattern but have been unlucky so far. Many fields with length of just 1 come back ok, but a few of length 1 are incorrect. Some fields bigger then length 1 are ok, but the majority come back with garbage. Coincidently or not, it almost looks like a hash of some sort. I'm wondering if there is a character on the datasource that's causing problems with DSEE figuring out where the end of the string is. I'm using NetBeans to look at the database, but I don't have direct access to the DB2 database at this point to see the data directly.
Has anyone experienced something simliar or have any suggestions as to further research of this problem?

Upon further testing I have found that the problem mentioned exists only when using ldapsearch. When I used an ldap browser, the char fields looked as expected.

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

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

JDBC Thin driver and Oracle names server

Hi
Any managed to get the Thin driver to user the Names Server aliases, ie I want to connect to service xxx like
jdbc:oracle:thin:@xxxx and not specify instance and port as the DB is running in a multiple machine cluster and can be switched to a different machine...
With OCI driver I have managed on NT but having problem with OCI/Linux and Beta 10g...
Tks
Andre

I don't have much experience with OCI from JDBC, but should work like any other kind of connection via SQL*Net. I.e. I would check if connection can be made using SQLPlus, check environment variables (ORACLE_HOME etc.) of 9iAS instance, check version of JDBC classes and their readme.txt. There are also some settings in sqlnet.ora file which might affect this (like default domain - try to use full name of alias - OCRL.WORLD or whatever alias you have there). You may also want to switch tracing for SQLNet and/or listener on (it's not easy to find in doc how to do it, though) to check if there is at least some traffic between klient and server...
Myrra

Bug 585844 JDBC Thin and Char Fields

Similar Messages

Maybe you are looking for