Reading CLOBS with ODBC

We are using Oracle 8.0.5 server on NT4.0 SP5, accessing it from our webserver, a Windows 2000 Server SP1, with the Oracle 8.00.510.00 ODBC driver. We are having problems with CLOBs using ADO and vbScript in ASP pages. We can write to a clob field fine, but when we read from it, we do not get an error, we get an empty string. Are we using the correct driver?
We know that the write is working because we can view it via SQL*Plus, but yet we cannot read it.
Any ideas? I'm still searching your site for articles, as well as MSDN and newsgroups. Thanks!

Similar Messages

Problem while reading clob with Stream

Hi
I'm trying to read some clob data from database using Streams.
Here is the simple code of what I'm trying to do
Environment *env = Environment::createEnvironment("JA16SJIS", "OCCIUTF16", Environment::THREADED_MUTEXED);
Connection *conn = env->createConnection("user", "pass", "database");
Statement stmt = conn->createStatement("SELECT FROM TABLE");
ResultSet *rs = stmt->executeQuery();
char buffer[65536];
rs->setCharacterStreamMode(3, 65536);
while (rs->next ())
     Stream* stream = rs->getStream (3);
     int r = stream->readBuffer(buffer, 65536);
     rs->closeStream(stream);
        ..I call setCharacterStreamMode method for the right column and than iterate through recordset. But if i just iterate through the recordset without reading stream data, the second call of rs->next() crash the program.
Any idea what this could be, and why the application crash if I don't read the entire stream? Is there some catch with Streams?

Thx, I just thought that there is some other way to avoid the whole stream reading.
Thx anyway

Error While reading CLOB from Oracle using WebLogic Connection Pool, Works fine with out using pool

PROBLEM DESCRIPTION :
     When I try to read a clob from Oracle, I receive "ORA-03120: two-task
conversion routine: integer overflow" Error.
     This error occurs only for CLOB Type and only if I try to connect to
Oracle using WebLogic JDriver/Oracle POOL.
     IMPORTANT NOTE: I can read CLOB or any other data using direct JDBC
connection to ORacle with out any problem.
     Below Please find the JAVA CODE for Both Working and NON Working .
Created a Connection Pool as:
Name: MyJDBCConnectionPool
URL : jdbc:weblogic:oracle
DIRVER:weblogic.jdbc.oci.Driver
NON WORKING JAVA CODE (USES WEBLOGIC JDBC CONNECTION POOL TO ORACLE):
Driver myDriver =
(Driver)Class.forName("weblogic.jdbc.pool.Driver").newInstance();
Connection mconn =
myDriver.connect("jdbc:weblogic:pool:MyJDBCConnectionPool",null);
mconn.setAutoCommit (false);
CallableStatement cs = mconn.prepareCall("{call
P_XMLTEST2(?)}"); //This returns a CLOB
cs.registerOutParameter(1,java.sql.Types.CLOB);
cs.execute();
Clob clob = null;
clob = cs.getClob(1);
String data =new String();
data = clob.getSubString(1, (int)clob.length());
System.out.println(data); //print the data
data = null;
clob=null;
cs.close();
WORKING JAVA CODE (USES DIRECT THIN JDBC CONNECTION TO ORACLE):
Driver myDriver =
(Driver)Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
Connection mconn =
myDriver.connect("jdbc:oracle:thin:@server:1521:DB",null);
mconn.setAutoCommit (false);
CallableStatement cs = mconn.prepareCall("{call
P_XMLTEST2(?)}"); //This returns a CLOB
cs.registerOutParameter(1,java.sql.Types.CLOB);
cs.execute();
Clob clob = null;
clob = cs.getClob(1);
String data =new String();
data = clob.getSubString(1, (int)clob.length());
System.out.println(data); //print the data
data = null;
clob=null;
cs.close();
ERROR MESSAGE:
     ORA-03120: two-task conversion routine: integer overflow
I appreciate your help on this problem.

PROBLEM DESCRIPTION :
     When I try to read a clob from Oracle, I receive "ORA-03120: two-task
conversion routine: integer overflow" Error.
     This error occurs only for CLOB Type and only if I try to connect to
Oracle using WebLogic JDriver/Oracle POOL.
     IMPORTANT NOTE: I can read CLOB or any other data using direct JDBC
connection to ORacle with out any problem.
     Below Please find the JAVA CODE for Both Working and NON Working .
Created a Connection Pool as:
Name: MyJDBCConnectionPool
URL : jdbc:weblogic:oracle
DIRVER:weblogic.jdbc.oci.Driver
NON WORKING JAVA CODE (USES WEBLOGIC JDBC CONNECTION POOL TO ORACLE):
Driver myDriver =
(Driver)Class.forName("weblogic.jdbc.pool.Driver").newInstance();
Connection mconn =
myDriver.connect("jdbc:weblogic:pool:MyJDBCConnectionPool",null);
mconn.setAutoCommit (false);
CallableStatement cs = mconn.prepareCall("{call
P_XMLTEST2(?)}"); //This returns a CLOB
cs.registerOutParameter(1,java.sql.Types.CLOB);
cs.execute();
Clob clob = null;
clob = cs.getClob(1);
String data =new String();
data = clob.getSubString(1, (int)clob.length());
System.out.println(data); //print the data
data = null;
clob=null;
cs.close();
WORKING JAVA CODE (USES DIRECT THIN JDBC CONNECTION TO ORACLE):
Driver myDriver =
(Driver)Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
Connection mconn =
myDriver.connect("jdbc:oracle:thin:@server:1521:DB",null);
mconn.setAutoCommit (false);
CallableStatement cs = mconn.prepareCall("{call
P_XMLTEST2(?)}"); //This returns a CLOB
cs.registerOutParameter(1,java.sql.Types.CLOB);
cs.execute();
Clob clob = null;
clob = cs.getClob(1);
String data =new String();
data = clob.getSubString(1, (int)clob.length());
System.out.println(data); //print the data
data = null;
clob=null;
cs.close();
ERROR MESSAGE:
     ORA-03120: two-task conversion routine: integer overflow
I appreciate your help on this problem.

HOW to read CLOB and create XML file on UNIX/LINUX

Hi,
Could you please let me know, how to read CLOB using ADODB. I have column CLOB type on Oracle 9.2, with content of whole XML type. I am unable to retreive more than 4k. I use adLongVarChar. So I have written Oracle stored procedure to read the clob and create XML file using DBMS_LOB package and UTL_FILE package, still no joy.
Please help.
example of my XML file is:
<EXAMPLE><HEADER><VERSION>1.0</VERSION><TEMPLATE>XXXX</TEMPLATE><TAG1>CON</TAG1></HEADER><BODY><TAG2>X1</TAG2><OFFICE>assad</OFFICE><CREATE_DATE>27/02/2006 10:55</CREATE_DATE><SOURCE></SOURCE></BODY><FIXEDTABLE1><TABLEROW1COL1>asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd</TABLEROW1COL1><TABLEROW1COL2></TABLEROW1COL2><TABLEROW2COL1></TABLEROW2COL1><TABLEROW2COL2></TABLEROW2COL2><TABLEROW3COL1></TABLEROW3COL1><TABLEROW3COL2></TABLEROW3COL2><TABLEROW4COL1>asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd asdadddddddddddddddddddddddddddddddddddddddddddddddddd</TABLEROW4COL1><TABLEROW4COL2></TABLEROW4COL2><TABLEROW5COL1></TABLEROW5COL1><TABLEROW5COL2></TABLEROW5COL2></FIXEDTABLE1><CHECKBOX><CHECKBOX1>False</CHECKBOX1><CHECKBOX2>False</CHECKBOX2><CHECKBOX3>False</CHECKBOX3><CHECKBOX4>False</CHECKBOX4><CHECKBOX5>False</CHECKBOX5><CHECKBOX6>False</CHECKBOX6><CHECKBOX7>False</CHECKBOX7><CHECKBOX8>False</CHECKBOX8><CHECKBOX9>False</CHECKBOX9></CHECKBOX></EXAMPLE>
My STored Procedure:
ftypFileHandle := UTL_FILE.fopen ('XML_DIR_FILE', vFileName, 'w', 32000);
lMarker := 'Selecting XML row';
println(lMarker, 2);
SELECT XML_FILE
INTO clobBuffer
FROM XML_TABLE
WHERE x=1;
lMarker := 'Get length of the clob';
iClobLength := nvl(DBMS_LOB.getlength(clobBuffer), 0);
WHILE (l_offset <= iClobLength) LOOP
DBMS_LOB.READ (
lob_loc=> clobBuffer,
amount=> l_amt,
offset=> l_offset,
buffer=> vOutputBuffer
UTL_FILE.put (ftypFileHandle, vOutputBuffer);
UTL_FILE.fflush (ftypFileHandle);
UTL_FILE.new_line (ftypFileHandle);
l_offset := l_offset + l_amt;
END LOOP;
lMarker := 'Close file';
println(lMarker, 2);
UTL_FILE.fclose (ftypFileHandle);
Thanks

Hello myself,
nobody has answered my question, so now I answer myself!!
The wrong part is to read the file with "open dataset" and to create the inputstream with
p_istream = p_streamfactory->create_istream_itable(
table = g_xml_table
size = g_xml_size ).
Better ist to create the inputstream with
p_istream = p_streamfactory->create_istream_uri(
.......................PUBLIC_ID = ''
.......................SYSTEM_ID = '
applserver\I$\TEMP\Datei.XML' ).
In this way no space is needed for the file.
Best regards,
Thomas
Message was edited by:
Thomas13 Scheuermann

Filling clob with non ascii characters

Hello,
I have had some problems with clobs and usage of german
umlauts (��). I was'nt able to insert or update
strings containing umlaute in combination with string
binding. After inserting or updating the umlaut
characters were replaced by strange (spanish) '?'
which were upside down.
However, it was working when I did not use string bindung.
I tried varios things, after some time I tracked
the problem down to to oracle.toplink.queryframework.SQLCall.java. In the
prepareStatement(...) you find something
like
ByteArrayInputStream inputStream = new ByteArrayInputStream(((String) parameter).getBytes());
// Binding starts with a 1 not 0.
statement.setAsciiStream(index + 1, inputStream,((String) parameter).getBytes().length);
I replaced the usage of ByteArrayInputStram with CharArrayReader:
// TH changed, 26.11.2003, Umlaut will not work with this.
CharArrayReader reader = new CharArrayReader(((String) parameter).toCharArray());
statement.setCharacterStream(index + 1, reader, ((String) parameter).length() );
and this worked.
Is there any other way achieving this? Did anyone
get clobs with non ascii characters to work?
Regards -- Tobias
(Toplink 9.0.3, Clob was mapped to String, Driver was Oracle OCI)

I don't think the console font is the problem. I use Lat2-Terminus16 because I read the Beginner's Guide on the wiki while installing the system.
My /etc/vconsole.conf:
KEYMAP=de
FONT=Lat2-Terminus16
showconsolefont even shows me the characters missing in the file names; e.g.: Ö, Ä, Ü

File upload with ODBC

Hi,
I want to upload a file using only the ODBC functions available in PHP to a oracle DB (i'm using a blob column, if this is not correct, please tell me).
I tried uploading it as a "normal" query but it doesn't work, oracle gives error...
So i'm asking if someone could give some snippets of code, tips, links, anything about this issue. Or if this is simply not possible to do with ODBC...
Thanks in advance for your time

This might help.
$handle = fopen($_FILES['filename']['tmp_name'],'r');
$file_content = fread($handle,filesize($_FILES['filename']['tmp_name']));
fclose($handle);
$encoded = chunk_split(base64_encode($file_content));
then the $encoded variable would be used as you blob column value.
Then when retrieving the value you would need to base64_decode() the data to get it back into the original form.
Hopefully this helps.

Instant client with ODBC driver

Hi, I have problem with the instant client version 10.2 with ODBC driver. I have the instant client base package and ODBC package installed in my computer. the Oracle ODBC driver did appear in the ODBC driver list, when I test the connection with driver, it gives error "Unable to connect, SQLState=08004 [ORACLE] [ODBC] ORA-12154 TNS could not resolve the connect identifier specified" I have another computer which has Oracle 8i client installed and works fine. I copied sqlnet.ora and tnsnames.ora to the instantclient installation folder, same error appears. here is the contents of sqlnet.ora:
# SQLNET.ORA Network Configuration File: c:\oracle8i\network\admin\sqlnet.ora
# Generated by Oracle configuration tools.
SQLNET.AUTHENTICATION_SERVICES= (NTS)
NAMES.DIRECTORY_PATH= (TNSNAMES)
here is the contents of tnsname.ora:
# TNSNAMES.ORA Network Configuration File: c:\oracle8i\network\admin\tnsnames.ora
# Generated by Oracle configuration tools.
barkeep =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = xxx.xxx.xxx.xxx)(PORT = 1521))
(CONNECT_DATA =
(SID = barkeep)
I test the host connection with telnet, it works.
can anybody out there walk me through how to set up instant client?
thanks.

Thanks Sanjay - I had this problem and your suggestion fixed it: setting the TNS_ADMIN did the trick.
Note: This was on a development PC which already had the Oracle Client drivers installed (so I already had a different TNS_NAMES.ORA in that installation).
It is worth noting that on my target deployment machine which DOESN'T have the Oracle Client drivers (just the InstantClient + Instant-ODBC) I didn't need to set TNS_ADMIN
I'm using the 11g InstantClient (11.1.0.6.0 32 bit)
Hope this helps someone, and thanks again Sanjay for posting :o)

Can I connect to SAP database directly with ODBC?

I need to read data from SAP and write them into ms sqlserver. I wrote a RFC in SAP and used VB.NET to call RFC. I wonder that the RFC efficency is very slow while reading a great lot data. RFC also cannot support complex condition string, and it cannot fetch my data flexibly.
I found that the user who was included in a user group "db<sid>adm" could connect to db2 udb with ODBC in VB6.0 or VB.NET. I also can use the SQL sentence to get data flexibly.
Please tell me whether I can use this user to read (just using select sentense) data from DB2 UDB directly, or whether I can use the newly created user to get data. Will this method cause any problem ?

> Will this method cause any problem ?
Pretty likely: yes, it will.
You may want to read this thread Retrive Data From SAP Using C Language first (and the blogs I refered to in it).
What it boils down to is: you're trying a super-low-level access to data in order to perform a high-level business data exchange.
You could as well hex-read the data files of the database or the blocks from your hard disks.
There are a bunch of options to remote access data in SAP systems and maybe your RFC can be tuned to better support your needs.
But don't move over to the 'dark side' of direct database access
regards,
Lars

Connect Lotus Notes with ODBC driver

I am trying to figure out connecting SQL Developer with ODBC connection ( set on to ODBC Data Source ) for lotus notes. I am able successfully connect through Excel with that connection. With SQL Developer , its asking for JDBC driver but lotus notes version (R5) what I am using does not support JDBC driver.
Is there any way to connect using ODBC data source for lotus notes.

No.
SQL Developer is a Java based tool and requires JDBC. Theoretically you could use the JDBC-ODBC bridge, but there would be no point. SQL Developer is an Oracle specific development and query tool which allows connection to selected other DBMSs in order to support migration to Oracle. Lotus Notes is not one of the supported systems.
SQL Developer is NOT a general purpose, multi-DBMS tool.

Why can't read clob

in oracle 8.1.7, I can read clob success; but can't execute in 8.1.6. the error info is :
ORA-03120: two-task conversion routine: integer overflow
please help me! please help me!
example code:
myClob = rs.getClob("content");
Reader instream = myClob.getCharacterStream();
char[] buffer = new char[10];
int length = 0;
while ((length = instream.read(buffer)) != -1) {
out.print("Read " + length + " chars: ");
for (int i=0; i<length; i++) out.print(buffer);
instream.close();

Hi there,
I am not a php expert, but worked with C, C++, Perl and Java systems working with Oracle database.
Oracle 10g is very flexible and advanced in term of LOBs and CLOBs (you can retrive CLOBs like any other type, can create indexes on CLOB columns and all string functions can work with CLOBs).
When we retrive Oracle CLOB into another language, we need to look at the facilities provided by driver software interacting with Oracle.
In Oracle, you can simply do 'select clob_column from table'. Question is, how the php driver can handle that CLOB data? Can you create a ref cursor and retrive the data? can you create a stream of data and extract the clob (like in C)? or can you simply create a php veriable of unlimited size and select the clob into it (like in Perl)?
See if this link is relevant for you
http://www.oracle.com/technology/pub/articles/oracle_php_cookbook/fuecks_lobs.html
Please let us know which solution did you implement.
Regards

Read CLOB error: ORA-03120

Can anyone help me?
When I use sql*plus to read CLOB field I got the error: ORA-03120 (tow task conversion routine: Integer overflow), why?
my client:
OS: NT2000
ORACLE: 8.1.6i
my server:
OS: Solaris 8
ORACLE: 8.1.6i

Difficult to be precise without knowing database characterset and what language you are trying to view. But keep in mind, when a client application operates with a terminal that uses a different character set, then the client application's characters must be converted to the database character set and vice versa. This conversion is done automatically but depends on the NLS_LANG setting and the database character set. The character set used by the client application in this case SQL*PLUS is defined by the NLS_LANG parameter

About call the store procedure using VB with ODBC

I want to ask how can I use the vb with ODBC call the oracle's store procedure ? I try to pass the parameter from vb and return 1 result, it is ok, but when I try to pass 1 parameter with return mutiple result (put it in recordset), the error message occured(Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available, No work was done) why ?? I can success whit using OLE DB, but why not in ODBC ?? does anybody can help me ?? Thanks a lot.

oh, really ? it is not use ODBC to connecto to oracle ?
Here is my program code:
STORE PROCEDURE:
PROCEDURE getInforcePolicy(PClient_ID IN VARCHAR2, PPolicy_No IN VARCHAR2, BasicCur OUT oraoledb.m_refcur, RiderCur OUT oraoledb.m_refcur)
IS
BEGIN
OPEN BasicCur FOR SELECT * FROM
inforce200111 WHERE Client_ID = PClient_ID and Policy_No = PPolicy_No and coverage_No = 1;
OPEN RiderCur FOR SELECT * FROM
inforce200111 WHERE Client_ID = PClient_ID and Policy_No = PPolicy_No and coverage_No <> 1;
END getInforcePolicy;
PACKAGE oraoledb AS
TYPE m_refcur IS REF CURSOR;
END oraoledb;
Program:
Dim cn As New ADODB.Connection
Dim rs As New ADODB.Recordset
Dim rs2 As New ADODB.Recordset
Dim cmd As New ADODB.Command
Dim paramclient As New ADODB.Parameter
Dim parampolicy As New ADODB.Parameter
Dim I As Integer
cn.Open "ridev", "abc","abc"
cmd.ActiveConnection = cn
Set paramclient = cmd.CreateParameter("PClient", adVarChar, adParamInput, 10)
Set parampolicy = cmd.CreateParameter("PPolicy", adVarChar, adParamInput, 10)
paramclient.Value = "0000023011"
parampolicy.Value = "HK0010021U"
cmd.Parameters.Append paramclient
cmd.Parameters.Append parampolicy
cmd.CommandText = "{call getInforcePolicy}"
Set rs = cmd.Execute
Do While Not rs.EOF
Loop
Set rs2 = rs.NextRecordset
Do While Not rs2.EOF
loop
Where the RIDEV is a datasource that created from Data Source in Control Panel using the driver call "Microsoft ODBC for ORACLE"

Database fileds are not coming when connecting with ado and they are coming when connecting with odbc

Post Author: yagya
CA Forum: .NET
Hi , I am using crystal report XI R2 in visual studio 2005 . Backend is sql server 2000. I have made a connection with odbc connectivity and using dsn. I am using a stored procedure as datasource of report. It is working fine all the database fields are available. Now when i try to connect with the ado connection having same stored procedure as datasource of report , I am not getting data fields. I dont know where is the problem in my stored procedure or in report. But when i connect through system dsn using odbc connectivity everything is working fine. A MAP filed dialogue box appears when i try to change the datasource location to ado from odbc.

There is a barely acknowledged issue. For Mac users Apple has released an update to the app, but for iOS users the recommendation is for users to update their ipad to the most recent operating system.
There may be a fix coming for iOS6 users (which seem to be many of those having problems) or there may not be. If your ipad isn't up to date then you can update it and see if that helps, or if you don't want to update then you may want to wait and see if there is either a fix or if it fixes itself.

SqlPlus with ODBC

Hi all
I install Oracle9i Lite on WIN2000 Pro
I want to connect to database with sqlplus
through ODBC.
I use 'scott/tiger@odbc:polite' connection string
and get following error:
'ORA-03121: no interface driver connected - function not performed'
What this error meaning and how I can avoid it.
Thanks.

Thanks for reply.
But I want to use OCI with ODBC
and SqlPlus I use only for
testing purposes.

Weblogic 8.1/Oracle 9 Writing and Reading Clob

I’m trying to write and read a clob to a database table. The database table has
an Id field (int) and a Content field (clob).
My environment consists of Weblogic 8.1, and Oracle 9. Is there a way to get a
handle to a Weblogic connection to Oracle and then write and read clobs?
Any help would be greatly appreciated!
Thanks,
Mike

Problem 1. US7ASCII and Linux - Status Resolved.
The issue with the BEA 817 JDBC driver not connecting to the US7ASCII database tuned out to be that it had not deployed the connection pool correctly from the weblogic admin console... or that it was reported as being deployed when in fact it was not. After re-deploying the connection pool and restarting the server we were able to connect.
The patch was for character sets was not needed.
Problem 2. Oracle Stored Proc error.
The problem with the stored procedures tunred out to be with ref cursors. A patch in sp3, and a change to the way we called the stored proc allowed us to fix the problem.
The problem is reproduced when connecting to an Oracle 8.1.7 server.
It was introduced in the Connect JDBC driver build 3.0.0007. According
to the jdbcread.me file which comes with the 3.0.0007 build we
deprecated the refCursorSupport connection property. This could be
related to the driver not being able to execute a stored procedure
containing ref cursors.
Resolution
Driver was fixed in the Connect JDBC 3.1 Oracle driver version 3.1.0008
The trick was to use
"{call PROC(?,?)}"
instead of
"BEGIN PROC(?, ?);
END;"
Here is a very useful link on the matter:
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=b860627b.0405130528.4db317a0%40posting.google.com&rnum=1&prev=/groups%3Fq%3D%255BBEA%255D%255BOracle%2BJDBC%2BDriver%255DInvalid%2Bparameter%2Bbinding%26hl%3Den%26lr%3D%26ie%3DUTF-8%26selm%3Db860 27b.0405130528.4db317a0%2540posting.google.com%26rnum%3D1
The bea type 4 is an oem from DataDirect
http://knowledgebase2.datadirect.com/kbase.nsf/26536a530e20a22b85256e550079afc2/b3be8f8fcb7c30c285256c9f006f8645?OpenDocument&Highlight=0,oracle

Reading CLOBS with ODBC

Similar Messages

Maybe you are looking for