SQLJ , CLOB and JDEV1.1

Hi,
I have a problem when i try to read a CLOB with JDev 1.1 in my
SQLJ file.
When i Build my Prg i have the following message:
Warning: The Type oracle.jdbc.driver.OracleClob of host item
ORARequeteSQL (at position #1) is not permitted in JDBC. This
will not be portable.
When I execute my Applet in the AppletViewer, I have the
following message on SQLException:
java.sql.SQLException: unable to convert database class
java.lang.String to client class oracle.jdbc.OracleClob
Below, you can see the SQLJ which generate this message:
public String SQLRecupRequeteSQL(int iNumQuery) throws
SQLException
long lLongSQL;
OracleClob ORARequeteSQL;
String sRequeteSQL = new String();
#sql { select libelle into :ORARequeteSQL from
edcnx.requete where num_query=:iNumQuery};
#sql lLongSQL={values(dbms_lob.getlength
(:ORARequeteSQL)) };
#sql { call dbms_lob.read
(:ORARequeteSQL,:lLongSQL,0,:sRequeteSQL) };
return(sRequeteSQL);
null

David,
The semantics for using LOB datatypes in JDBC and SQLJ are
covered in the SQLJ Client Developer's Guide and Reference. Here
is an example of how to access a CLOB from that guide.
void readFromClob(OracleClob clob) throws SQLException
long clobLen, readLen;
String chunk;
#sql clobLen = { values(dbms_lob.getlength(:clob)) };
for (long i = 1; i <= clobLen; i += readLen) {
readLen = 10;
#sql { call dbms_lob.read(:clob, :inout readLen, :i, :out chunk)
System.out.println("read " + readLen + " chars: " + chunk);
Regards,
PSW
DUPONT David (guest) wrote:
: Hi,
: I have a problem when i try to read a CLOB with JDev 1.1 in my
: SQLJ file.
: When i Build my Prg i have the following message:
: Warning: The Type oracle.jdbc.driver.OracleClob of host item
: ORARequeteSQL (at position #1) is not permitted in JDBC. This
: will not be portable.
: When I execute my Applet in the AppletViewer, I have the
: following message on SQLException:
: java.sql.SQLException: unable to convert database class
: java.lang.String to client class oracle.jdbc.OracleClob
: Below, you can see the SQLJ which generate this message:
: public String SQLRecupRequeteSQL(int iNumQuery) throws
: SQLException
: long lLongSQL;
: OracleClob ORARequeteSQL;
: String sRequeteSQL = new String();
: #sql { select libelle into :ORARequeteSQL from
: edcnx.requete where num_query=:iNumQuery};
: #sql lLongSQL={values(dbms_lob.getlength
: (:ORARequeteSQL)) };
: #sql { call dbms_lob.read
: (:ORARequeteSQL,:lLongSQL,0,:sRequeteSQL) };
: return(sRequeteSQL);
null

Similar Messages

Again : SQLJ, CLOB and JDEV2.0 BETA (BUG !!)

After reading the ORACLE DOCUMENTATION about using of CLOB in a
SQLJ file, i try this:
package Pack_ConnexionOracle;
import sqlj.runtime.*;
import sqlj.runtime.ref.*;
import java.sql.*;
// Importing the Oracle Jdbc driver package makes the code more
readable
import oracle.jdbc.driver.*;
public class OraCrit
public OraCrit(String Surl,String Susr,String Spwd)
try
DriverManager.registerDriver(new
oracle.jdbc.driver.OracleDriver());
DefaultContext.setDefaultContext(new DefaultContext
(Surl,Susr,Spwd));
catch(Exception ex)
ex.printStackTrace();
public String SQLRecupRequeteSQL(int iNumQuery) throws
SQLException
long lLongSQL;
OracleClob ORARequeteSQL;
String sRequeteSQL = new String();
#sql { select requete_sql into :ORARequeteSQL from requete where
num_query=:iNumQuery };
#sql lLongSQL={values(dbms_lob.getlength(:ORARequeteSQL)) };
#sql { call dbms_lob.read
(:ORARequeteSQL,:lLongSQL,0,:sRequeteSQL) };
return(sRequeteSQL);
at the line 61:
#sql { select requete_sql into :ORARequeteSQL from requete where
num_query=:iNumQuery };
I have this compilation error:
Error:(61) Liste of links Variables INTO...Prohibited: illegal
expression
at the line 62:
#sql lLongSQL={values(dbms_lob.getlength(:ORARequeteSQL)) };
I have this compilation error:
Error:(62) The Java type doesn't exist for the host element n 1..
at the line 63:
#sql { call dbms_lob.read
(:ORARequeteSQL,:lLongSQL,0,:sRequeteSQL) };
Same message than at line 62.
Is it possible to use a CLOB in SQLJ with JDeveloper 2.0 Beta?
HELP ME PLEASE,
Thanks a lot.............
null

Hi David,
I saw your previous posts. I'm a different person than the one
who responded earlier. I am going to post your question to our
internal SQLJ mailing list to get some more help.
What version of the database are you connecting to? I noticed in
your first post, you were using Jdev 1.1, so I thought you might
be running against 8.0.
-L
David DUPONT (guest) wrote:
: After reading the ORACLE DOCUMENTATION about using of CLOB in a
: SQLJ file, i try this:
: package Pack_ConnexionOracle;
: import sqlj.runtime.*;
: import sqlj.runtime.ref.*;
: import java.sql.*;
: // Importing the Oracle Jdbc driver package makes the code more
: readable
: import oracle.jdbc.driver.*;
: public class OraCrit
: public OraCrit(String Surl,String Susr,String Spwd)
: try
: DriverManager.registerDriver(new
: oracle.jdbc.driver.OracleDriver());
: DefaultContext.setDefaultContext(new DefaultContext
: (Surl,Susr,Spwd));
: catch(Exception ex)
: ex.printStackTrace();
: public String SQLRecupRequeteSQL(int iNumQuery) throws
: SQLException
: long lLongSQL;
: OracleClob ORARequeteSQL;
: String sRequeteSQL = new String();
: #sql { select requete_sql into :ORARequeteSQL from requete
where
: num_query=:iNumQuery };
: #sql lLongSQL={values(dbms_lob.getlength(:ORARequeteSQL)) };
: #sql { call dbms_lob.read
: (:ORARequeteSQL,:lLongSQL,0,:sRequeteSQL) };
: return(sRequeteSQL);
: at the line 61:
: #sql { select requete_sql into :ORARequeteSQL from requete
where
: num_query=:iNumQuery };
: I have this compilation error:
: Error:(61) Liste of links Variables INTO...Prohibited: illegal
: expression
: at the line 62:
: #sql lLongSQL={values(dbms_lob.getlength(:ORARequeteSQL)) };
: I have this compilation error:
: Error:(62) The Java type doesn't exist for the host element n
1..
: at the line 63:
: #sql { call dbms_lob.read
: (:ORARequeteSQL,:lLongSQL,0,:sRequeteSQL) };
: Same message than at line 62.
: Is it possible to use a CLOB in SQLJ with JDeveloper 2.0 Beta?
: HELP ME PLEASE,
: Thanks a lot.............
null

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

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

Replicating clobs and blobs in a remote database across dblink

9iR2
When creating a materialized view in a warehouse pointing to a remote table in an OLTP environment, I got this error when trying to replicate a table with 3 clobs.
ORA-22992: cannot use LOB locators selected from remote tables
So, how does Oracle recommend replicating Blobs and Clobs in a remote database/warehouse? Evidently using materialized views doesnt work.

MV replication is obsolete.
Move to 10gR2 and use Streams.

CLOBs and Dynamic SQL method 4

We have just added CLOBs ( select_dp->T == 112 ) to our applications. We have a application tier server that is a Pro*C program that reads and iterprets some "extended" .sql files. We this server uses dynamic sql method 4, with host arrays, etc. The docs say you cannot do a FETCH FOR <value> with CLOBs, but you can ALLOCATE and FREE the clobLocator with a FOR clause. What good is the ALLOCATE and FREE "FOR" if you can't FETCH with a FOR ?? Can you really select clobs along with typical varchars??

Can you tell me exactly where are you going to use the Dynamic SQL method 4 ? so that i can help you in using the method.
Thiagu.

SQLJ , CLOB and JDEV1.1

Similar Messages

Maybe you are looking for