Jbuilder正确连接 oracle 9i需要注意的几个问题
oracle8以上的应该都使用classes12.jar文件作为jdbc驱动;
正确设置windows的classpath和jbuilder中的enterprise setup 、configure libraries,将casses12.jar路径正确添加到上述需要设置的地方;
进入database pilot,在database pilot中,file---new 在driver列表中如果oracle的驱动是红色的,就说明你的oralce在jb中加载失败;
若③没有错,则新建一个url:jdbc:oracle:thin:@(yourhostname):1521:(your sid)
连接数据库的Username/password
注:大部分站友的jbuilder连接oracle的问题都是由于没有正确配置classpath等引起的。
使用非XA方式连接ORACLE数据库
在windows下配置Oracle_XA时要注意两点:
#ORACLE 10
Oracle_XA;xaosw;%ORACLE_HOME% dbms oraxa10.lib%ORACLE_HOME%precompibmsvcorasql10.lib
#oracle 9
Oracle_XA;xaosw;%ORACLE_HOME% dbms oraxa9.lib%ORACLE_HOME%precompibmsvcorasql9.lib
Unix下
Oracle_XA:xaosw:....
第一:在windows 下 ORACLE_XA 和xaosw后面的是分号";",不是冒号":"
第二:上面的这些LIB写在一行上,中间用空格分开,如果没有在系统的环境变量中设置ORACLE_HOME,就写绝对路径。
JDBC操作ORACLE数据库时出现‘java.sql.SQLException:IO异常,不在流模式下’
用OracleStatment,,不要用java.sql.Statment
如果对已有连接进行setAutoCommit失败,则关闭该连接并重新建立一个连接
到ORACLE站点下载一个最新的JDBC Driver,如果操作LOB类型,用ORACLE自带的接口和类
weblogic连接oracle问题:The Network Adapter could not establish the connection
可能是服务器的监听停掉了,是数据库的问题,与应用无关;应该先检查一下oracle是否正常,用sql*plus连接一下数据库,看能否正常连接;
Weblogic中使用Oracle连接池及Oracle备份的注意事项
使用HP-UNIX,Weblogic 8.1,Oracle 9.2.0.5
配置了一个普通的连接池,驱动程序采用oracle的Oracle’s Driver(Thin) version 9.0.1, 9.2.0
错误情况:
结果使用数据库连接池时报错,说没有连接池资源了。实际上数据库的连接池完全空闲,并且测试也是对的,Oracle也是正常可以连接、使用的。
问题根源:
通过层层排错,发现原来后台在使用Oracle的exp备份一个只有同义词的用户,导致exp进程僵死。
杀死exp、重启Oracle等无法解决问题,最终重启UNIX,禁止备份只有同义词的用户,问题解决。
总结:
应该是Oracle9的exp BUG导致连接池问题,不要使用exp倒出同义词
连接Oracle时抛出如下异常:java.sql.SQLException: Io exception:The Network Adapter could not establish connection一种产生原因
Oracle Database Connection (from oracle.com)
PROBLEM
You are attempting to connect to an Oracle instance using JDBC and you are receiving the following error.
java.sql.SQLException: Io exception:
The Network Adapter could not establish connection
SQLException: SQLState (null) vendor code (17002)
Any or all of the following conditions may also apply:
1) You are able to establish a SQL*Plus connection from the same
client to the same Oracle instance.
2) You are able to establish a JDBC OCI connection, but not a Thin
connection from the same client to the same Oracle instance.
3) The same JDBC application is able to connect from a different
client to the same Oracle instance.
4) The same behavior applies whether the initial JDBC connection
string specifies a hostname or an IP address.
REDISCOVERY
To verify whether you are hitting this problem, verify whether the Oracle instance is configured for Multithreaded Server (MTS). If the Oracle instance is not configured for MTS, you are probably encountering a different problem. Otherwise, continue. Try forcing the JDBC connection to use a dedicated server instead of a shared server. This can be accomplished in several ways. For JDBC OCI or Thin, this can be done by reconfiguring the server for dedicated connections only. This approach, however, may not be feasible in many cases. In such cases, the following options apply: For JDBC OCI:
1) Add the (SERVER=DEDICATED) property to the TNS connect string
stored in the tnsnames.ora file on the client.
2) Set the user_dedicated_server=ON in sqlnet.ora on the client.
For JDBC Thin:
You must specify a full name-value pair connect string (the same as it might appear in the tnsnames.ora file) instead of the short JDBC Thin syntax. For example, instead of
"jdbc:oracle:thin::port:sid"
you would need to use a string of the form
"jdbc:oracle:thin:@(DESCRIPTION=" +
"(ADDRESS_LIST=" +
"(ADDRESS=(PROTOCOL=TCP)" +
"(HOST=host)" + =
"(PORT=port)" +
")" +
")" +
"(CONNECT_DATA=" +
"(SERVICE_NAME=sid)" +
"(SERVER=DEDICATED)" +
")" +
")"
If the connection works fine after having made these changes, it is very likely that this is the problem you are encountering. In this case, one last test will help to verify this fact.
Log into the remote host on which the Oracle instance is running and execute the appropriate command to determine what the server 'thinks' its hostname is (i.e. the name that was configured when the server was installed and configured). For example, on a Unix host the 'hostname' command can be used for this purpose.
Using the name displayed (e.g. by the hostname command), exactly as it appeared (i.e. if the output from the hostname command had the domain name included, then include it), return to the client which was unable to connect and try pinging the server.
NOTE: It is critical that you attempt to ping the server using EXACTLY the same hostname you got from the server.
If you are unable to ping the server via this hostname, then you almost certainly hitting th