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

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

RMS installation error: JDBC-thin client oracle/jdbc/driver/T2CConnection.getLibraryVersionNumber()

Trying to Install RMS application 13.2.2 and I get past the pre-installation checks and when I get to the Data Source details and enter the data source details with the check box checked to validate the schema/Test Data Source I get the following error:
Error Connecting to database URL jdbc:oracle:oci:@rmsdbtst as user rms13 java.lang.Exception:UnsatisfiedLinkError encountered when using the Oracle driver. Please check that the library path is set up properly or switch to the JDBC thin client oracle/jdbc/driver/T2CConnection.getLibraryVersioNumber()
Checks performed:
RMS Application code location and directory contents:
[oracle@test-rms-app application]$ pwd
/binary_files/STAGING_DIR/rms/application
[oracle@test-rms-app application]$ ls -ltr
total 144
-rw-r--r-- 1 oracle oinstall   272 Dec 7 2010 version.properties
-rw-r--r-- 1 oracle oinstall   405 Jan 16 2011 expected-object-counts.properties
-rw-r--r-- 1 oracle oinstall   892 May 13 2011 ant.install.properties.sample
-rw-r--r-- 1 oracle oinstall 64004 Jun 6 2011 build.xml
drwxr-xr-x 9 oracle oinstall 4096 Jun 16 2011 rms13
drwxr-xr-x 3 oracle oinstall 4096 Jun 16 2011 installer-resources
drwxr-xr-x 3 oracle oinstall 4096 Jun 16 2011 antinstall
drwxr-xr-x 2 oracle oinstall 4096 Jun 16 2011 ant-ext
drwxr-xr-x 5 oracle oinstall 4096 Jun 16 2011 ant
-rw-r--r-- 1 oracle oinstall 11324 Dec 18 09:18 antinstall-config.xml.ORIG
-rwxr-xr-x 1 oracle oinstall 4249 Dec 18 10:01 install.sh
drwxr-xr-x 4 oracle oinstall 4096 Dec 18 10:06 common
-rw-r--r-- 1 oracle oinstall 16244 Dec 19 10:37 antinstall-config.xml
-rw-r--r-- 1 oracle oinstall   689 Dec 19 10:37 ant.install.log
[oracle@test-rms-app application]$
Application installation:
[oracle@test-rms-app application]$ ./install.sh
THIS IS the driver directory
Verified $ORACLE_SID.
Verified SQL*Plus exists.
Verified write permissions.
Verified formsweb.cfg read permissions.
Verified Registry.dat read permissions.
Verified Java version 1.4.2.x or greater. Java version - 1.6.0
Verified Tk2Motif.rgb settings.
Verified frmcmp_batch.sh status.
WARNING: Oracle Enterprise Linux not detected. Some components may not install properly.
Verified $DISPLAY - 172.16.129.82:0.0.
This installer will ask for your "My Oracle Support" credentials.
Preparing installer. This may take a few moments.
Your internet connection type is: NONE
Integrating My Oracle Support into the product installer workflow...
     [move] Moving 1 file to /binary_files/STAGING_DIR/rms/application
Installer preparation complete.
MW_HOME=/u01/app/oracle/Middleware/NewMiddleware1034
ORACLE_HOME=/u01/app/oracle/Middleware/NewMiddleware1034/as_1
ORACLE_INSTANCE=/u01/app/oracle/Middleware/NewMiddleware1034/asinst_1
DOMAIN_HOME=/u01/app/oracle/Middleware/NewMiddleware1034/user_projects/domains/rmsClassDomain
WLS_INSTANCE=WLS_FORMS
ORACLE_SID=rmsdbtst
JAVA_HOME=/u01/app/oracle/jrockit-jdk1.6.0_45-R28.2.7-4.1.0
Launching installer...
To make sure I have connectivity from the app server to the database (on a database server) here are the steps followed:
[oracle@test-rms-app application]$ tnsping rmsdbtst
TNS Ping Utility for Linux: Version 11.1.0.7.0 - Production on 19-DEC-2013 10:41:40
Copyright (c) 1997, 2008, Oracle. All rights reserved.
Used parameter files:
Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = test-rms-db.vonmaur.vmc)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = rmsdbtst)))
OK (0 msec)
[oracle@test-rms-app application]$
[oracle@test-rms-app application]$ sqlplus rms13@rmsdbtst
SQL*Plus: Release 11.1.0.7.0 - Production on Thu Dec 19 10:46:18 2013
Copyright (c) 1982, 2008, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> exit
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
[oracle@test-rms-app application]$
[oracle@test-rms-app application]$ ping test-rms-db
PING test-rms-db.vonmaur.vmc (192.168.1.140) 56(84) bytes of data.
64 bytes from test-rms-db.vonmaur.vmc (192.168.1.140): icmp_seq=1 ttl=64 time=0.599 ms
64 bytes from test-rms-db.vonmaur.vmc (192.168.1.140): icmp_seq=2 ttl=64 time=0.168 ms
64 bytes from test-rms-db.vonmaur.vmc (192.168.1.140): icmp_seq=3 ttl=64 time=0.132 ms
64 bytes from test-rms-db.vonmaur.vmc (192.168.1.140): icmp_seq=4 ttl=64 time=0.158 ms
64 bytes from test-rms-db.vonmaur.vmc (192.168.1.140): icmp_seq=5 ttl=64 time=0.135 ms
--- test-rms-db.vonmaur.vmc ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4001ms
rtt min/avg/max/mdev = 0.132/0.238/0.599/0.181 ms
[oracle@test-rms-app application]$
[oracle@test-rms-app application]$ uname -a
Linux test-rms-app.vonmaur.vmc 2.6.18-128.el5 #1 SMP Wed Jan 21 08:45:05 EST 2009 x86_64 x86_64 x86_64 GNU/Linux
[oracle@test-rms-app application]$
[oracle@test-rms-app application]$ cat /etc/*-release
Enterprise Linux Enterprise Linux Server release 5.3 (Carthage)
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
[oracle@test-rms-app application]$
The database is created and all the batch file scripts have been successfully deployed. Now working on the application server. The Weblogic server is installed and 11g forms and reports are installed successfully.
Any help would be helpful.
Thanks,
Ram.

Please check MOS Notes:
FAQ: RWMS 13.2 Installation and Configuration (Doc ID 1307639.1)

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 driver Oracle 8.1.5 on Solaris

I have a problem where a query is running slow when using a JDBC driver but it runs fine when executed through SQL Plus. I've traced the JDBC connection and TKPROF shows that the query plan and says it's taking 3.4 Seconds to run. But, the query is taking more than a minute to run via the JDBC driver. The query joins 4 tables and does do full tablescans. But still executes in 3 or 4 seconds.
Here is where things get strange. If I rebuild a particular index, and do an explain plan or trace the session, it uses the index and runs in .89 seconds. This query normally returns 4 rows or less. None of the columns are Blobs. Any idea why it would run so much slower using a JDBC driver?
null

I have the same problem in my project.
The environment is:
OS: Solaris 8
JDK: 1.2.2
DB: Oracle 8.1.5
JDBC driver: thin(included in Oracle 8.1.5)
The problem was solved when I replaced the JDBC driver with thin
8.1.6 or 8.1.7 (download from otn.oracle.com). There was no
error when I read 10000+ records.

JDBC THIN on Oracle 8.1.6 (7)

Hello and firstly, happy new year.
I would like to optimize a connection between an applet the drivers of Oracle (Thin) and a data base Oracle.
I have several question about the performance of this connection because
for a transfer of 150 KB of useful data (connection plsql on oracle
on line), I note a transfer of 600 KB between the applet
and the server !!
So:
- What kind of parameters can be configure on the Oracle Server to spped this transfer time (Size of the buffer?, Multi buffer? ).
- Is something to configure on the Java applet client?
- How to optimize this type of connection?
to sum up, I use the Oracle driver, is the Sun driver more powerful?
Thank you for your help.

for a transfer of 150 KB of useful data (connection
plsql on oracle on line), I note a transfer of 600 KB
between the applet and the server !!Nothing to do with Oracle or Sun.
The Oracle Thick (type-2) and thin (type-4) drivers talk to the DB server using the Oracle-proprietary "Net8" protocol. That happens to be verbose, and so that's what you get.
Using the JDBC-ODBC bridge is not going to make this any faster.
Your best bets are:
1. Have your applet talk to an intermediate server, which can query Oracle, get the results, compress it into a compact tabular format suitable for your applet (perhaps even using GZipOutputStream to really compress the data), and send it down.
2. Investigate some of the type-3 drivers out there (type-3 drivers are those that talk to an intermediate middleware server that can do query result caching and other such optimizations). See the lookup table at http://industry.java.sun.com/products/jdbc/drivers. Perhaps they do something like this with their data streams, though this would be a heavy hammer indeed if this is the only problem you're trying to solve..

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!

JDBC thin on Oracle

I loaded Oracle8, I start the TNS-Listener ($lsnrctl start), I am
not using Oracle names server.
I test the connection to Oracle8 whith JDBC thin, I use the
sample $ORACLE_HOME/jdbc/samples/thin/JdbcApplet.java
No problem on localhost, but i have problem (no connect on
Oracle8) whith another host on my network.
Please help me,
Abdallah
null

Abdallah (guest) wrote:
: I loaded Oracle8, I start the TNS-Listener ($lsnrctl start), I
am
: not using Oracle names server.
: I test the connection to Oracle8 whith JDBC thin, I use the
: sample $ORACLE_HOME/jdbc/samples/thin/JdbcApplet.java
: No problem on localhost, but i have problem (no connect on
: Oracle8) whith another host on my network.
: Please help me,
: Abdallah
I am not sure this if this is what is causing you trouble, but
I had to fix OOB (out-of-band breaks, the way Net8 handles
Crtl-C) setting on my Linux machines for them to
talk to each other using Net8.
I had to put "disable_oob = ON" in my sqlnet.ora to get Net8
working.
Good Luck !
Anwar.
null

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

EP 6.0 SP2 JDBC iView and Oracle Database

Hi,
I created Oracle system in Portal.
Then I creted JDBC iView for the system.
But iView always display the error:
"No response from the backend application".
And from portal log:
"CGT exception: java.lang.RuntimeException: bad execution, SQL Exception:[SAP_Portals][Oracle JDBC Driver][Oracle]ORA-00904: invalid column name"
Can anybody help me?
Thanks.

Dear Aviad,
Thnx a lot for your guidance, Incidentally we found the problem. For some reason the Portal was not able to resolve the ip address 132.12.33.30, but was able to resolve the host name "newspd".
This is the final url we created :
jdbc:sap:oracle://newspd:1521;SID=SALES
I'm able to create the iviews with the JDBC connection now, but the look is not so great, as there are a couple of problems :
1. The iview's table output has the raw column names showing as column titles. Atleast in SP2 there is no way to create a alternate column name. Ex: the table row name is say "amt_1", the column name in the iview also shows as "AMT_1". Is there a alternative for this problem ??
2. For passing parameters, the iview allows for only static parameters, but is there a way I can create a dynamic parameter allocation. Ex: In the query parameters I have a employee number as a included column, but I wish to show only his records to him, but in the portal environment, we havent a way to find the logged on employee ? Is there a way we can do that ??
Hope you'll be able to help.
Regards,
Neeraj S

XI 2.0, JDBC-Adapter and Oracle

Hello together,
at the moment I'm working on a scenario, at this I have to write data in a CLOB-Field of a table in a Oracle 9i database. My problem now is, that I only can write a string with a maximum length of 3000 chars directly in the database. To process longer strings I always write a stored procedure to handle this.
Does anybody know a direct solution.
Thank you,
Oli

Hi!!!
The database allows direct data insertion of up to 4K of data to a CLOB/BLOB column.
If you want to insert more data into CLOB field in the pure SQL (not in a stored procedure), then you have to do this in two steps:
1. insert a new row into the table.
2. update CLOB field of this just inserted row.
You can specified these two SQL statements by using one of the XML document formats (for outbound JDBC adapter).
Regards,
Andrzej Filusz

JDBC extensions and oracle execution

We've been using the format for date comparisons in JDBC of
SELECT COUNT(*) FROM WELL WHERE PI_COMP_DATE <= {d '1910-12-31'} ) ))
A question about this is what does the driver do to the "d" operator? Is the string converted into an optimal date type that will use the index on PI_COMP_DATE?
Thanks in advance!
Dallas

We've been using the format for date comparisons in JDBC of
SELECT COUNT(*) FROM WELL WHERE PI_COMP_DATE <= {d '1910-12-31'} ) ))
A question about this is what does the driver do to the "d" operator? Is the string converted into an optimal date type that will use the index on PI_COMP_DATE?
Thanks in advance!
Dallas

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 access to Oracle DB - nls_charset-12.jar

All,
I found this jar used by an application along with the oracle 9.x JDBC driver. Obviously an upgrade is required to the latest JDBC drivers. Does anyone know what nls_charset-12.jar is used for and if the new 11g version still requires it? I would assume there is only 1 jar file which would take care of JDBC communication with Oracle DB.
Thanks in advance!

>
Yes, I will have to support international characters as well. So this jar file is still required with Oracle 11g?
>
That file has been replaced with orai18n.jar which is clearly stated on the download page:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-112010-090769.html
The driver's readme also clearly explains for which character sets you need the ora18n.jar:
http://download.oracle.com/auth/otn/utilities_drivers/jdbc/112/Readme.txt?e=1302938175&h=f74ccdcb22412e9b88109cc11fc17b32
>
The JDBC Server-side Internal Driver provides complete NLS support.
It does not require any NLS extension jar file. Discussions in this
section only apply to the Oracle JDBC Thin and JDBC OCI drivers.
The basic jar files (ojdbc5.jar and ojdbc6.jar) contain all the
necessary classes to provide complete NLS support for:
- Oracle Character sets for CHAR/VARCHAR/LONGVARCHAR/CLOB type data
that is not retrieved or inserted as a data member of an Oracle
Object or Collection type.
- NLS support for CHAR/VARCHAR data members of Objects and
Collections for a few commonly used character sets. These
character sets are: US7ASCII, WE8DEC, WE8ISO8859P1, WE8MSWIN1252,
and UTF8.

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

JDBC Thin and Oracle 7.3.4

Similar Messages

Maybe you are looking for