CLOB and ADO

I have a table with a CLOB field that I need to retrieve using ADO 2.5 and OLEDB Provider for Oracle, 'MSDAORA.1'.
Everytime, I try to open up the table and get the following error, 'Data Type Is Not Supported'.
Thanks.

post this on the odbc or oledb forum.
this is a java forum

Similar Messages

Character sets and ado

I have a table with a clob field on an Oracle 8.1.7.4 database. When querying the clob field via odbc and ado the value is truncated. The Oracle server and client are using a WE8ISO8859P1 character set. Has anyone come across this before.
Thanks.

I believe the data should be able to be represented by IS0-8859. The data is a long random string of characters that represents a fingerprint image.
We seem to only get 996 characters back from the database. If I do a getchunk on the data then I get 996 characters of data, then 996 NULLS, then 996 characters of data and so on. The 996 NULLS should be data.
The data is in the database because I can do a dbms_lob.substr and get the correct info back.

Can't fetch clob and long in one select/query

I created a nightmare table containing numerous binary data types to test an application I was working on, and believe I have found an undocumented bug in Oracle's JDBC drivers that is preventing me from loading a CLOB and a LONG in a single SQL select statement. I can load the CLOB successfully, but attempting to call ResultSet.get...() for the LONG column always results in
java.sql.SQLException: Stream has already been closed
even when processing the columns in the order of the SELECT statement.
I have demonstrated this behaviour with version 9.2.0.3 of Oracle's JDBC drivers, running against Oracle 9.2.0.2.0.
The following Java example contains SQL code to create and populate a table containing a collection of nasty binary columns, and then Java code that demonstrates the problem.
I would really appreciate any workarounds that allow me to pull this data out of a single query.
import java.sql.*;
This class was developed to verify that you can't have a CLOB and a LONG column in the
same SQL select statement, and extract both values. Calling get...() for the LONG column
always causes 'java.sql.SQLException: Stream has already been closed'.
CREATE TABLE BINARY_COLS_TEST
PK INTEGER PRIMARY KEY NOT NULL,
CLOB_COL CLOB,
BLOB_COL BLOB,
RAW_COL RAW(100),
LONG_COL LONG
INSERT INTO BINARY_COLS_TEST (
PK,
CLOB_COL,
BLOB_COL,
RAW_COL,
LONG_COL
) VALUES (
1,
'-- clob value --',
HEXTORAW('01020304050607'),
HEXTORAW('01020304050607'),
'-- long value --'
public class JdbcLongTest
public static void main(String argv[])
throws Exception
Driver driver = (Driver)Class.forName("oracle.jdbc.driver.OracleDriver").newInstance();
DriverManager.registerDriver(driver);
Connection connection = DriverManager.getConnection(argv[0], argv[1], argv[2]);
Statement stmt = connection.createStatement();
ResultSet results = null;
try
String query = "SELECT pk, clob_col, blob_col, raw_col, long_col FROM binary_cols_test";
results = stmt.executeQuery(query);
while (results.next())
int pk = results.getInt(1);
System.out.println("Loaded int");
Clob clob = results.getClob(2);
// It doesn't work if you just close the ascii stream.
// clob.getAsciiStream().close();
String clobString = clob.getSubString(1, (int)clob.length());
System.out.println("Loaded CLOB");
// Streaming not strictly necessary for short values.
// Blob blob = results.getBlob(3);
byte blobData[] = results.getBytes(3);
System.out.println("Loaded BLOB");
byte rawData[] = results.getBytes(4);
System.out.println("Loaded RAW");
byte longData[] = results.getBytes(5);
System.out.println("Loaded LONG");
catch (SQLException e)
e.printStackTrace();
results.close();
stmt.close();
connection.close();
} // public class JdbcLongTest

The problem is that LONGs are not buffered but are read from the wire in the order defined. The problem is the same as
rs = stmt.executeQuery("select myLong, myNumber from tab");
while (rs.next()) {
int n = rs.getInt(2);
String s = rs.getString(1);
The above will fail for the same reason. When the statement is executed the LONG is not read immediately. It is buffered in the server waiting to be read. When getInt is called the driver reads the bytes of the LONG and throws them away so that it can get to the NUMBER and read it. Then when getString is called the LONG value is gone so you get an exception.
Similar problem here. When the query is executed the CLOB and BLOB locators are read from the wire, but the LONG is buffered in the server waiting to be read. When Clob.getString is called, it has to talk to the server to get the value of the CLOB, so it reads the LONG bytes from the wire and throws them away. That clears the connection so that it can ask the server for the CLOB bytes. When the code reads the LONG value, those bytes are gone so you get an exception.
This is a long standing restriction on using LONG and LONG RAW values and is a result of the network protocol. It is one of the reasons that Oracle deprecates LONGs and recommends using BLOBs and CLOBs instead.
Douglas

ODP and ADO and a trigger - problem

I have written a simple trigger to turn on tracing for a session based on the username:
It works fine through sqlplus. The application works when run using JDBC and native(?) java. But when we use hibernate and ODP.net and ADO.net The session goes into a loop of recursive sql and gets an ORA-36 too many recursive levels. I am not a java developer and I am at a loss on how to proceed. It appears to be firing the trigger or have fired the trigger, and then look for global_db_name until it dies.
CREATE OR REPLACE TRIGGER gopal_user_login_trigger
AFTER LOGON ON DATABASE
DECLARE
     user_name VARCHAR2(30);
BEGIN
SELECT username INTO user_name FROM sys.V$SESSION
WHERE audsid = USERENV('SESSIONID') AND audsid != 0 ;
IF UPPER(user_name) = 'GOPALASSETUSER'
THEN
     DBMS_MONITOR.SESSION_TRACE_ENABLE(NULL, NULL, true, true);
END IF;
EXCEPTION
WHEN NO_DATA_FOUND then null;
END;

Hi,
Thanks for the bug number - that helped alot.
Why the global_db_name lookup, I do not know. It appears to be part of the logon processing that follows the trigger.It is, indeed, part of the logon process and is called by internal code so that makes sense now.
If you have MetaLink support, I would recommend opening an SR. One simple thing that I might suggest is to set "enlist=false" in your connect string if you can and test with that.
Thanks,
Mark

Problem with java.sql.Clob and oracle.sql.CLOB

Hi,
I am using oracle9i and SAP web application server. I am getClob method and storing that in java.sql.Clob and using the getClass().getName() I am getting the class name as oracle.sql.CLOB. But when I am trying to cast this to oracle.sql.CLOB i am getting ClassCastException. The code is given below
java.sql.Clob lOracleClob = lResultSet.getClob(lColIndex + 1);
lPrintWriter = new PrintWriter(new BufferedWriter (((oracle.sql.CLOB) lOracleClob).getCharacterOutputStream()));
lResourceStatus = true;
can anybody please tell me the what is the problem with this and solution.
thanks,
Ashok.

Hi Ashok
You can get a "ClassCastException" when the JVM doesn't have access to the specific class (in your case, "oracle.sql.CLOB").
Just check your classpath and see if you are referring to the correct jar files.
cheers
Sameer
PS: Please award points if you find the answer useful

Poor performance in select on CLOB (and actually anything not kept inrow)

Hello,
Creating a table with RAW(16) as primary key (GUID), CLOB
and inserting some hundred-thousands up to 10 million records.
Selects on this table are a randomly chosen (by sample query) 500-1000 ids from the table, then fetching
the CLOB data, takes about 16-20 secs for 1000 records.
Anyone have a clue on how to make these kind of selects faster. We are aiming at 5 seconds top for this kind of query.
Or is it too much to expect ?
The select itself is done as join which temporary table containing the id (which is better than just using the IN operator).
Regards,
Rani

hi
I alsow have a problem when i work with clobs , even doing the 10046 trace , there is still time un-accounted for , see my test case at [clob test case|http://forums.oracle.com/forums/message.jspa?messageID=3474400#3474400] although its just inserting/appending the clob.

Mapping CLOB and Long in xml schema

Hi,
I am creating an xml schema to map some user defined database objects. For example, for a column which is defined as VARCHAR2 in the database, I have the following xsd type mapping.
<xsd:element name="Currency" type="xsd:string" />
If the oracle column is CLOB or Long(Oracle datatype), could you please tell me how I can map it in the xml schema? I do not want to use Oracle SQL type like:
xdb:SQLType="CLOB" since I need a generic type mapping to CLOB. Would xsd:string still hold good for CLOB as well as Long(Oracle datatype) ?
Please help.
Thanks,
Vadi.

The problem is that LONGs are not buffered but are read from the wire in the order defined. The problem is the same as
rs = stmt.executeQuery("select myLong, myNumber from tab");
while (rs.next()) {
int n = rs.getInt(2);
String s = rs.getString(1);
The above will fail for the same reason. When the statement is executed the LONG is not read immediately. It is buffered in the server waiting to be read. When getInt is called the driver reads the bytes of the LONG and throws them away so that it can get to the NUMBER and read it. Then when getString is called the LONG value is gone so you get an exception.
Similar problem here. When the query is executed the CLOB and BLOB locators are read from the wire, but the LONG is buffered in the server waiting to be read. When Clob.getString is called, it has to talk to the server to get the value of the CLOB, so it reads the LONG bytes from the wire and throws them away. That clears the connection so that it can ask the server for the CLOB bytes. When the code reads the LONG value, those bytes are gone so you get an exception.
This is a long standing restriction on using LONG and LONG RAW values and is a result of the network protocol. It is one of the reasons that Oracle deprecates LONGs and recommends using BLOBs and CLOBs instead.
Douglas

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

Read CLOB and parse out records

I have a table that features an XMLTYPE column containing CLOB data with XML and HTML content in it. I'm not quite sure how I can parse out the [CDATA] section and create a unique list of IDs contained within the javascript:openLink() string. Any ideas? I've tried searching the forums for how to read a CLOB and parse out each line, but didn't find the results I was looking for.
I've provided a sample of some of the content in this column:
<html><![CDATA[
<P>
<font face="Arial" SIZE="3">
<strong>
<span style="FONT-FAMILY: Arial">Recruiting</span>
</strong>
</font>
</P>
<P>
<A CLASS="divHyperLink" href="javascript:openLink(1010)">2008 Newsletters</A>
</P>
<P>
<A CLASS="divHyperLink" href="javascript:openLink(1009)">2007 Newsletters</A>
</P>
<P>
<A CLASS="divHyperLink" href="javascript:openLink(1008)">2006 Newsletters</A>
</P>
]]></html>
I basically need to output a list of IDs:
LinkID
1010
1009
1008

Sorry...I thought I could figure things out based on your example, but I 'm not sure if 10g supports noentityescaping clause. Do you happen to know what I would need to substitute it with? To my understanding the XMLELEMENT function takes a name for "identifier," although I'm not quite sure in this case what the identifier should be...an XML tag value?
This is SQL I tried to run but not getting any results:
SELECT t2.*
FROM (SELECT pagecontent
FROM tb_rh_page
WHERE pageid = 1) T,
XMLTABLE('a/@href' PASSING XMLELEMENT(noentityescaping, EXTRACTVALUE(T.pagecontent,'/p_PAGECONTENT/Controls/divTopLeft/html/text()')).EXTRACT('//a')
COLUMNS linkid integer PATH 'ora:replace(.,"[^[:digit:]]","")') t2
Also the HTML is a little deeper in the XML than I originally posted, so I'm not sure if I'm getting to the path correctly.
Here's what the data looks like in the column:
<p_PAGECONTENT>
<PageName/>
<Title/>
<Roles/>
<Controls>
<PageTool>
<visible>false</visible>
</PageTool>
<divTopLeft>
<visible>true</visible>
<style>font-size:larger;overflow:auto;FILTER: progid:DXImageTransform.Microsoft.Gradient(StartColorStr=#3b6f9f, EndColorStr=#e6eff6);Height:560px;background-color:#003366;border-bottom-width: 1px;border-color: #c6ddf1;border-left-width: 1px;border-right-width: 1px;border-style: Solid;border-top-width: 1px;</style>
<html><![CDATA[
<P>
<font face="Arial" SIZE="3">
<strong>
<span style="FONT-FAMILY: Arial">Recruiting</span>
</strong>
</font>
</P>
<P>
<A CLASS="divHyperLink" href="javascript:openLink(1010)">2008 Newsletters</A>
</P>
<P>
<A CLASS="divHyperLink" href="javascript:openLink(1009)">2007 Newsletters</A>
</P>
<P>
<A CLASS="divHyperLink" href="javascript:openLink(2008)">2006 Newsletters</A>
</P>
]]></html>
</divTopLeft>
<divTopRight>
<visible>false</visible>
<style/>
<html><![CDATA[]]></html>
</divTopRight>
<divBottomLeft>
<visible>false</visible>
<style/>
<html><![CDATA[]]></html>
</divBottomLeft>
<divBottomRight>
<visible>false</visible>
<style/>
<html><![CDATA[]]></html>
</divBottomRight>
</Controls>
</p_PAGECONTENT>

PL/SQL CLOB and comma seperated list

Hi,
i´am beginner!
I have a table with a clob field with a comma separeted list. The content can be '', '44' or '44,55...' as an example.
So how can i get the values in clob and search another table?
Something like...
select clob from table1
each clob
select * from table2
where table2.id = (clob value)
... do somtheing further
Thank you,
Jochen

Ok... it depends...
If you know your CLOB is going to hold a list of values that are less than 4000 characters, you can simply treat the CLOB as a VARCHAR2 and perform one of the many techniques for splitting that string to give a varying IN list...
e.g.
SQL> ed
Wrote file afiedt.buf
1 select *
2 from emp
3 where ename in (
4    with t as (select '&input_string' as txt from dual)
5    select REGEXP_SUBSTR (txt, '[^,]+', 1, level)
6    from t
7    connect by level <= length(regexp_replace(txt,'[^,]*'))+1
8*   )
SQL> /
Enter value for input_string: SCOTT,JAMES
old   4:   with t as (select '&input_string' as txt from dual)
new   4:   with t as (select 'SCOTT,JAMES' as txt from dual)
     EMPNO ENAME      JOB              MGR HIREDATE                   SAL       COMM     DEPTNO
      7788 SCOTT      ANALYST         7566 19-04-1987 00:00:00       3000                    20
      7900 JAMES      CLERK           7698 03-12-1981 00:00:00        950                    30
SQL>(or alternatively read here: http://tkyte.blogspot.com/2006/06/varying-in-lists.html)
If it's going to exceed the SQL VARCHAR2 limit of 4000 characters then you would most likely need to create a Pipelined function to split your CLOB into it's component values and return each one, thus allowing you to treat the results as a table of their own... e.g.
Note: this example is for a pipelined function that splits a varchar2 string, but you could adapt it to use the DBMS_LOB package to split a CLOB in the same manner...
SQL> CREATE OR REPLACE TYPE split_tbl IS TABLE OF VARCHAR2(4000);
2 /
Type created.
SQL> CREATE OR REPLACE FUNCTION split (p_list VARCHAR2, p_delim VARCHAR2:=' ') RETURN SPLIT_TBL PIPELINED IS
2      l_idx    PLS_INTEGER;
3      l_list   VARCHAR2(4000) := p_list;
4      l_value VARCHAR2(4000);
5    BEGIN
6      LOOP
7        l_idx := INSTR(l_list, p_delim);
8        IF l_idx > 0 THEN
9          PIPE ROW(SUBSTR(l_list, 1, l_idx-1));
10          l_list := SUBSTR(l_list, l_idx+LENGTH(p_delim));
11        ELSE
12          PIPE ROW(l_list);
13          EXIT;
14        END IF;
15      END LOOP;
16      RETURN;
17    END SPLIT;
18 /
Function created.
SQL> SELECT column_value
2 FROM TABLE(split('FRED,JIM,BOB,TED,MARK',','));
COLUMN_VALUE
FRED
JIM
BOB
TED
MARK
SQL> create table mytable (val VARCHAR2(20));
Table created.
SQL> insert into mytable
2 select column_value
3 from TABLE(split('FRED,JIM,BOB,TED,MARK',','));
5 rows created.
SQL> select * from mytable;
VAL
FRED
JIM
BOB
TED
MARK
SQL>... and once you can treat the values like a table it's just a case of using it like you would any table of values i.e. join on it or use it in an IN statment with a subselect etc.

How to extract data from CLOB and insert them into DB?

Hi PL/SQL Gurus,
I have no experience in PL/SQL, but I have a requirement now where I have to use it.
We have a table with 10 columns, one of them is a CLOB and it holds XML data. The XMLs are very huge in size.
Two new columns are added to the table and the data has to be filled for the existing records from the corresponding XML. The XML has all the data as attributes. I started searching on the internet and tried if I could extract the data out of XML.
SELECT extractValue(value(x), '/Order/Package/@Code',
'xmlns:ns0="http://mycompany.com/Order/OrderType.xsd"' )
FROM ORDER_TABLE A
, TABLE(
XMLSequence(
extract(
xmltype(A.XML_DATA)
, '/ns0:Root'
, 'xmlns:ns0="http://mycompany.com/Order/OrderType.xsd"'
) x;
But this isn't working. Could anyone please provide some ideas.
I just want to confirm that I am able to extract data. Once this is done I would like to create a procedure so that all the existing records can be updated.
Thanks in advance.
Regards,
Fazzy

Can this be acheived using a SQL statement.Yes, you can do it with the DML error logging clause.
Here's a quick example I've just set up :
Base table
SQL> create table order_table (
2   order_id number,
3   package_code varchar2(30),
4   package_desc varchar2(100),
5   xml_data clob
6 );
Table created
SQL> alter table order_table add constraint order_table_pk primary key (order_id);
Table altered
Adding data...
SQL> insert into order_table (order_id, xml_data)
2 values (1, '<?xml version="1.0" encoding="UTF-8"?>
3 <ns0:Root xmlns:ns0="http://mycompany.com/Order/OrderType.xsd" BookingDate="2009-06-07">
4 <ns1:OrderKey xmlns:ns1="http://mycompany.com/Order/OrderKeyTypes.xsd" SystemCode="THOMAS" Id="458402-TM1" Version="1"/>
5 <ns0:Package Code="0001" Desc="ProductName1"/>
6 <ns0:PromotionGroup Code="DSP" Name="OrderThomasPortal"/>
7 <ns0:Promotion Code="TH902" Name="OrderThomasPortal" SellingName="OrderThomasPortal" BackOfficeName="OrderThomasPortal"/>
8 <ns0:FinancialSupplier Code="HHT" Name="NYOrdSupp"/>
9 <ns0:SellingCurrency Code="EUR" Name="Euro"/>
10 <ns0:Owner ClientId="02654144" ClientMandator="T" ClientSystem="ROSY"/>
11 <ns0:Agent PersonInAgency="5254" AgentCode="000009" CommissionAmount="2.8" CommissionDueDate="2009-07-01+02:00" VatOnCommission="0"/>
12 </ns0:Root>');
1 row inserted
SQL> insert into order_table (order_id, xml_data)
2 values (2, '<?xml version="1.0" encoding="UTF-8"?>
3 <ns0:Root xmlns:ns0="http://mycompany.com/Order/OrderType.xsd" BookingDate="2009-06-07">
4 <ns1:OrderKey xmlns:ns1="http://mycompany.com/Order/OrderKeyTypes.xsd" SystemCode="THOMAS" Id="458402-TM1" Version="1"/>
5 <ns0:Package Code="0002" Desc="ProductName2/>
6 <ns0:PromotionGroup Code="DSP" Name="OrderThomasPortal"/>
7 <ns0:Promotion Code="TH902" Name="OrderThomasPortal" SellingName="OrderThomasPortal" BackOfficeName="OrderThomasPortal"/>
8 <ns0:FinancialSupplier Code="HHT" Name="NYOrdSupp"/>
9 <ns0:SellingCurrency Code="EUR" Name="Euro"/>
10 <ns0:Owner ClientId="02654144" ClientMandator="T" ClientSystem="ROSY"/>
11 <ns0:Agent PersonInAgency="5254" AgentCode="000009" CommissionAmount="2.8" CommissionDueDate="2009-07-01+02:00" VatOnCommission="0"/>
12 </ns0:Root>');
1 row inserted
SQL> commit;
Commit complete
{code}
Note that the second row inserted contains a not well-formed XML (no closing quote for the /Root/Package/@Desc attribute).
*Creating the error logging table...*
{code}
SQL> create table error_log_table (
2   ora_err_number$ number,
3   ora_err_mesg$   varchar2(2000),
4   ora_err_rowid$ rowid,
5   ora_err_optyp$ varchar2(2),
6   ora_err_tag$    varchar2(2000)
7 );
Table created
{code}
*Updating...*
{code}
SQL> update (
2    select extractvalue(doc, '/ns0:Root/ns0:Package/@Code', 'xmlns:ns0="http://mycompany.com/Order/OrderType.xsd"') as new_package_code
3         , extractvalue(doc, '/ns0:Root/ns0:Package/@Desc', 'xmlns:ns0="http://mycompany.com/Order/OrderType.xsd"') as new_package_desc
4         , package_code
5         , package_desc
6    from (
7      select package_code
8           , package_desc
9           , xmltype(xml_data) doc
10      from order_table t
11    )
12 )
13 set package_code = new_package_code
14    , package_desc = new_package_desc
15 log errors into error_log_table ('My update process')
16 reject limit unlimited
17 ;
1 row updated
SQL> select order_id, package_code, package_desc from order_table;
ORDER_ID PACKAGE_CODE                   PACKAGE_DESC
         1 0001                           ProductName1
         2
{code}
One row has been updated as expected, the other has been rejected and logged into the error table :
{code}
SQL> select * from error_log_table;
ORA_ERR_NUMBER$ ORA_ERR_MESG$                                                                    ORA_ERR_ROWID$     ORA_ERR_OPTYP$ ORA_ERR_TAG$
          31011 ORA-31011: XML parsing failed                                                    AAAF6PAAEAAAASnAAB U              My update process
                ORA-19202: Error occurred in XML processing
                LPX-00244: invalid use of less-than ('<') character (use <)
                Error at line 5
                ORA-06512: at "SYS.XMLTYPE", line 272
                ORA-06512: at line 1
{code}

How we handle CLOB and BLOB Datatypes in HANA DB

Dear HANA Gurus,
We have would like to build EDW using HANA base on our source system Oracle and it's supports CLOB and BLOB datatypes
Would you please suggest how do we handle in HANA DB.
Let not say it's oracle specific.
Regards,
Manoj

Hello,
check SAP HANA SQL Reference Guide for list of data types:
(page 14 - Classification of Data Types)
https://service.sap.com/~sapidb/011000358700000604922011
For this purpose might be useful following data types:
Large Object (LOB) Types
LOB (large objects) data types, CLOB, NCLOB and BLOB, are used to store a large amount of data such as text documents and images. The maximum size of an LOB is 2 GB.
BLOB
The BLOB data type is used to store large binary data.
CLOB
The CLOB data type is used to store large ASCII character data.
NCLOB
The NCLOB data type is used to store a large Unicode character object.
Tomas

OCFS supporting CLOB and SYS.XML

Hello,
I could not find a response to this in the Oracle documents.
Are CLOB and SYS.XML data type supported by OCFS?
We need to migrate a 9.2.0.4 Windows Database having these data types to a 9.2.0.4 Linux Real Application Cluster with OCFS. This could cause an issue
Philippe

Please read the FAQ Thread and follow the code examples shown thier for accessing XMLType from JAVA
eg
select XMLTYpe(clob_col_name)
and getObject() Avoid the OPAQUE stuff

Performance between CLOB and VARCHAR2

I would like to know if there is any really performance issues between CLOB and VARCHAR2 data types?
In particular, why would it not be better to declare all large text items as CLOB rather than VARCHAR2(4000) in a table? For example, if I am going to store about a page of text, in a table, why not standardize of CLOB? Only use VARCHAR2 for small text items.

I doubt that there would be much, if any, performance difference between a CLOB and a VARCHAR2. By default, Oracle will store CLOBS directly in the table if they are less than about 4000 bytes, so the effect would be the same as a VARCHAR2(4000).
The advantage of VARCHAR2(4000) over a CLOB is that you document and enforce the maximum size of the field. If you know that no test item will exceed 4000 bytes, then I would store it as a VARCHAR2, because if they can store more, someone will.
A possible disadvantage of using CLOBS instead of VARCHAR2(4000) is that when you declare a column as a CLOB, Oracle creates the two lob segments whether or not they are needed to actually store data. So, depending on how many VARCHAR2(4000) columns you change to CLOBS without needing to store more than 4000 bytes, you can potentially waste a significant amount of space.
SQL> CREATE TABLE t_clob (id NUMBER, descr CLOB);
Table created.
SQL> SELECT segment_name, index_name
2 FROM dba_lobs
3 WHERE table_name = 'T_CLOB';
SEGMENT_NAME                   INDEX_NAME
SYS_LOB0000136329C00002$$      SYS_IL0000136329C00002$$
SQL> SELECT segment_name, segment_type, blocks
2 FROM dba_segments
3 WHERE segment_name in ('SYS_LOB0000136329C00002$$','SYS_IL0000136329C00002$$')
SEGMENT_NAME                   SEGMENT_TYPE           BLOCKS
SYS_IL0000136329C00002$$       LOBINDEX                   64
SYS_LOB0000136329C00002$$      LOBSEGMENT                 64HTH
John

Clob DataType, NULL and ADO

Hello,
First, I'm french so my english isn't very good
I have a problem with Oracle Clob DataType. When I try to put NULL value to
CLOB DataType with ADO, changes aren't not made.
rs.open "SELECT ....", adocn, adOpenKeyset, adLockOptimistic
rs.Fields("ClobField") = Null ' In this case, the Update doesn't work
rs.update
rs.Close
This code works if I try to write a value which is different than Null but
not if is equal to Null. Instead of having Null, I have the old value
(before changes), the update of the field doesn't work.

I experience the same, did you find a solution to your problem?
Kind regards,
Roel de Bruyn

CLOB and ADO

Similar Messages

Maybe you are looking for