Storing and searching XML in CLOBs

Speaking to an oracle employee at the Oracle booth at JavaOne
recently. They suggested I store XML in CLOBs
and use the DOM or SAX to reparse the XML later as needed.
I agreed that this was the best solution for my problem
(which was how to manage many different XML documents using many
different DTDs in a document management system)
The big problem was searching this document repository
to locate relevant information.
This is where Intermedia seemed ideal (still does).
It would be nice to see an example of setting this up using
Intermedia in Oracle 8i, demonstrating how to define the
XML_SECTION_GROUP and where to use a ZONE as opposed to a FIELD
etc.
Anybody care to take a shot at this ????
For example:
How would I define Intermedia parameters
so that I would be able to search my CLOB
column for records that had the <keyword>
"aorta" and "damage" in the <caption>
using the following
XML (DTD implied)
<image filename="OurImageName.gif">
<fname>WellKnownFileName.gif</fname>
<keyword>echocardiogram</keyword>
<keyword>aorta</keyword>
<caption>This is an image of the vessel damage</caption>
</image>
Thanks
Thomas Bennett
null

Eric (guest) wrote:
: You can't do XML structure-based searches with intermedia. You
: can search for text within a given element, but nothing more
: complicated than that.
The example he gave involves exactly that -- searching for
text within XML elements. interMedia can do this.
: It also does not do attributes.
Upcoming 8.1.6 version allows searching within
attribute text. That's something like:
dog within book@author
We're working on attribute value sensitive search,
more like:
dog within book[@author = "Eric"]
: Thomas Bennett (guest) wrote:
: : How would I define Intermedia parameters
: : so that I would be able to search my CLOB
: : column for records that had the <keyword>
: : "aorta" and "damage" in the <caption>
: : using the following
: : XML (DTD implied)
: : <image filename="OurImageName.gif">
: : <fname>WellKnownFileName.gif</fname>
: : <keyword>echocardiogram</keyword>
: : <keyword>aorta</keyword>
: : <caption>This is an image of the vessel damage</caption>
: : </image>
begin
ctx_ddl.create_section_group('mygrp','basic_section_group');
ctx_ddl.add_field_section('mygrp','keyword','keyword');
ctx_ddl.add_field_section('mygrp','caption','caption');
end;
create index myidx on mytab(mytxtcolumn)
indextype is ctxsys.context
parameters ('section group mygrp');
select * from mytab
where contains(mytxtcolumn, 'aorta within keyword')>0;
options:
* use XML section group instead of basic section group
if your tags have attributes or you need case-sensitive
tag detection
* use zone sections instead of field sections if your
sections overlap, or if you need to distinguish
between instances. For instance, keywords. If keywords
is a field section, then
(aorta and echocardiogram) within keywords
finds the document. if it is a zone section, then it
doesn't, because they are not in the SAME instance of
keywords.
null

Similar Messages

  • Storing and Updating XML-documents in interMedia

    Hi,
    I have an idea to do the following with the help of interMedia.
    We work with 8.1.7 at the moment.
    Is this a feasable or not???
    1) Receive lots and lotts of XML-messages.
    2) Store each one of all these XML-messages in a CLOB (maybe divide the XML-message into a few smaler parts for Read only and for Update)
    3) Search these XML-messages.
    4) Display the result in a list.
    5) Present one of these XML-message in HTML.
    6) Manipulate it throug HTML and uppdate the original XML-message in its CLOB.
    Is this possible or not!
    Please help me in answering this or give me directions to where i can find an answer!
    Roland

    Hi,
    http://www.dom4j.org/
    Hope this helps
    Jakub Krecicki

  • Any Recommendation for storing and searching metadata

    Hi all,
    We upload images to the DB and extract the DICOM, IPTC, XMP and EXIF fields in the DB as xmltypes. This works good.
    Now I am wondering what the recommended way is to make these fields searchabe by the user. I have tried to create an index over those fields, which works ok, but updating them when images are uploaded or removed takes a long time (with jobs).
    Also we need to write those fields back to the image. I read the reference and saw that the example suggest to write a new XML file and then write this back to the image. I only saw the example with XMP, but I guess I can do that with IPTC too, or? If so any examples? Our application allows the user to edit and add new keywords and those fields need to be stored back to the image.
    TIA for any answers.

    OK, we only support replacing Metadata in XMP format.
    Also, we do not support replacing metadata with DICOM medical images.
    Do you have a write up of your application? If we onderstood what you were trying to do, we would be in a better position to make recommendations, like what kind of indexing to use. If possible, you could send it to me at [email protected]
    If you have interMedia requirements, send them to [email protected]
    Larry

  • Importing and Searching XML Text

    I am new to Flash programming, but have done some work in
    PHP, ASP and Frontier. I am trying to build a Flash file that
    imports an XML price list and then allows the user to input a
    four-digit part number. When a button is clicked, I'd return from
    that XML list the items that match the input along with their
    prices. The XML file would look something like this:
    <?xml version="1.0" encoding="utf-8"?>
    <prodlist>
    <item>
    <id>1001121</id>
    <prod>7558-02</prod>
    <um></um>
    <price>10.56</price>
    <index>Y</index>
    </item>
    <item>
    <id>1001181</id>
    <prod>7557-02</prod>
    <um></um>
    <price>18.49</price>
    <index>Y</index>
    </item>
    <item>
    <id>1001191</id>
    <prod>7557-04</prod>
    <um></um>
    <price>20.69</price>
    <index>Y</index>
    </item>
    </prodlist>
    Naturally, I'd have to parse the six-digit part numbers down
    to four, and I think I can figure that one out.
    I have been able to read in the XML file, but can't figure
    out how to access it via a button click and return the
    searched-upon items. I know this may be a bit of a broad request,
    but I was hoping someone might at least point me in a direction so
    I can figure this out. I also can't seem to figure out how to tie
    an external .AS file to a particular .FLA file.
    Flash 3.0 seems really cool and robust, but boy, for a newbie
    like me there is quite the learning curve!

    Ok, playing around with this, but it appears that the only
    item being returned to the text field is the LAST one in the XML
    file. So, when I do a search for 7557, although it DOES run through
    the loop twice, only part #7557-04 is being written to the text
    field. And if I do a search on 7558 (the first part in the XML), I
    get the "part not found message". So I'm guessing that for some
    reason the script is only addressing the last XML item being
    searched. Here's my code:
    var xmlLoader:URLLoader = new URLLoader();
    var xmlData:XML = new XML();
    xmlLoader.addEventListener(Event.COMPLETE, LoadXML);
    xmlLoader.load(new URLRequest("test.xml"));
    function LoadXML(e:Event):void {
    xmlData = new XML(e.target.data);
    ParseBooks(xmlData);
    function ParseBooks(bookInput:XML):void {
    var prodList:XMLList = bookInput.item;
    for (var i:int = 0; i < prodList.length(); i++) {
    var prodItem = bookInput.item.prod.text()
    var priceItem = bookInput.item.price.text();
    var hyphenPos = prodItem.indexOf("-");
    var finalProd = prodItem.slice(0,hyphenPos);
    var inputfield = new TextField( );
    inputfield.text = "";
    inputfield.width = 150;
    inputfield.height = 30;
    inputfield.border = true;
    inputfield.background = true;
    inputfield.type = TextFieldType.INPUT;
    addChild(inputfield);
    var t:TextField = new TextField( );
    t.background = true;
    t.backgroundColor = 0xCCCCCC;
    t.border = true;
    t.borderColor = 0x333333;
    t.autoSize = TextFieldAutoSize.LEFT;
    t.wordWrap = true;
    t.y=200;
    addChild(t);
    function makeCircle():Sprite {
    var circle:Sprite = new Sprite();
    circle.name = name;
    circle.graphics.lineStyle(0);
    circle.graphics.beginFill(0xFF8080);
    circle.graphics.drawCircle(50, 50, 50);
    return circle;
    var circle:Sprite = makeCircle();
    circle.x=100;
    circle.y=100;
    addChild(circle);
    circle.addEventListener(MouseEvent.MOUSE_DOWN, click);
    function click(e) {
    for (var obj in xmlData.children()) {
    var prodItem = xmlData.children()[obj].prod.text()
    var hyphenPos = prodItem.indexOf("-");
    var finalProd = prodItem.slice(0,hyphenPos);
    if (finalProd==inputfield.text) {
    t.text=xmlData.children()[obj].prod.text()+"\n"
    +"\n"+xmlData.children()[obj].price.text();
    } else {
    t.text="The part you searched for was not found";
    }

  • Keyword setup and searching...

    Hello,
    I'm looking for an example of the best way to set up keyword
    searching in CF. I'm using CF 7 with just an Access 2k3 database.
    The application is a document management system for storing
    and searching PDF's, Word files, Powerpoint files, etc. I'd like to
    have the upload form give the user a choice of about 6 or so
    keywords to choose from. There would also be a description field,
    author, product name, and doc type. Just the keyword search and
    storage of these values is what I'm curious about.
    I know that Verity would be able to search the documents
    themselves but that's not quite what I'm looking for. If possible
    I'd also like a way to 'score' search results to better place
    higher matches.
    Any help is appreciated.

    Yes, this is a bug. I suspect the developers never considered that Users would have so many keywords.
    There is a workaround. Use Keyword Manager to manage your keywords, and to search with them too. It has significant advantages over the inbuilt keywording mechanism.
    nor does Apple allow me to simply type in a keyword for search purposes.
    Yes it does. Just type the keyword in the Search Box. You don't even have to select Keyword from the Drop Down.
    Thanks Apple!
    I'm sure they'd say "You're Welcome!"
    Can I submit bug reports online to Apple? No - you have to be in their developer program for that it seems.
    No, you can do it simply enough using the iPhoto menu -> Provide iPhoto Feedback command.
    Thanks Apple!
    I'm sure they'd say "You're Welcome!" for that too.
    neither of those problems will directly give you revenue Apple
    Oh, you seem to think you're talking to Apple here, haven't you read the Terms of Use? You agreed to them when you signed up and there's a link to them on the right hand side of every page. As they explain, this is a forum for Users to discuss technical issues with other Users. Apple's developers aren’t here. They don’t promise to read anything here. To reach Apple use the Feedback link above.
    Regards
    TD

  • XML in clob columns and OWB

    I’m building some ETL process to extract data from XML in CLOB columns. I know that there are solutions to use functions as extractvalue() of WB_XML_LOAD(), but I want to know if there is any other way to deal with XML. The reason for that is because my XML files have multiple namespaces and nodes, and I need something more complex to deal with that, since I already tried those two first solutions.
    My first solution was to create a PL/SQL that parses the XML and looks for tags and elements. It populates a relational table, and I might use OWB to extract the data from this table. But I’m dealing with a large table and it takes a while for processing, plus my code is hude!
    My question is: Does someone have any experience with complex XML in Clob columns? If so, what was your solution for that?
    Thanks a lot!
    Angelo Buss
    [email protected]

    CLOB is a fully-updateable, character large object that is stored inside the database. It can be text-indexed using interMedia for document searching.
    BFILE is a readonly pointer to a file on the external file system whose content is not physically stored in the database. It can also be text-indexed for document searching, but it can't be updated.

  • How to store XML and search within tags

    My question
    ===========
    exactly what steps do you need follow to take an XML doc, store
    it, and query based on a tag value.
    The 8i Intermedia text option Reference refers to
    XLM_SECTION_GROUP feature. However, no examples are given. There
    is no user guide.
    I searched Oracle's website and found one reference to
    XML_SECTION_GROUP. The example given is a single row insert into
    a CLOB column with a single pair of tags.
    This whitepaper gives an example of an XML doc, and a query on
    it:
    XML Support in Oracle8i and Beyond
    November 9, 1998
    It doesn't list the steps in between storing the doc and quering
    it. This is crucial to the whole thing: does XML_SECTION_GROUP
    allow all nested tags below the top level to be sectioned and
    indexed implicitly? Or do you need to tell Oracle about all the
    tags you are interested in, in which case what value is added by
    the XLM_SECTION_GROUP?
    Does Oracle have some better examples on this?
    Below is text cut and pasted from the whitepaper.
    -----------x---------
    Figure 5: InsuranceClaim Mixes Structured Data and Text
    <?xml version="1.0"?>
    <InsuranceClaim>
    <ClaimID>12345</ClaimID>
    <LossCategory>7</LossCategory>
    <Settlements>
    <Payment>
    <Payee>Borden Real Estate</Payee>
    <Date>12-OCT-1998</Date>
    <Amount>200000</Amount>
    <Approver>JCOX</Approver>
    </Payment>
    </Settlements>
    <DamageReport>
    A massive <Cause>Fire</Cause> ravaged the building
    and
    <Casualties>12</Casualties> people were killed.
    Early
    FBI reports indicate that <Motive>arson</Motive> is
    suspected.
    </DamageReport>
    </InsuranceClaim>
    Once instances of iFS file types (including XML-based ones) are
    stored in the database, their
    content can be searched using standard SQL queries, and these
    files can be organized, browsed,
    and versioned using familiar tools like the Windows Explorer.
    So an insurance agent sees a
    directory of InsuranceClaim files sheFs recently worked on in
    the field, while an
    InsuranceClaim-processing application developer can work with
    the information in the
    InsuranceClaim in any way he needs to.
    XML-Enabled "Section Searches" in ConText
    Any XML documents or document fragments saved into "text blobs"
    in the database can be
    enabled for indexing by Oracle8i InterMediaFs ConText
    text-search engine. ConText has been
    enhanced for Oracle8i to allow developers to pinpoint their
    searches to a particular section of a
    document, where sections are implicitly defined by the XML tags
    in the document (fragment).
    Since ConText is seamlessly integrated into the database and
    the SQL language, developers can
    use SQL to perform queries that involve both structured data
    and indexed document fragments.
    For example, Figure 6 shows the SQL statement you would write
    to search one million
    Insurance Claims in your database to answer the question, "How
    much money has Jim Cox
    approved to date in settlement payments for arson-related fire
    claims? "
    Figure 6: Searching on a Column & Text in XML
    Sections
    SELECT SUM(Amount)
    FROM Claim_Header ch,
    Claim_Settlements cs,
    Claim_Settlement_Payments csp
    WHERE csp.Approver = 'JCOX'
    AND CONTAINS (DamageReport, 'Arson WITHIN Motive') >
    0
    AND CONTAINS (DamageReport, 'Fire WITHIN Cause' ) >
    0
    AND . . . /* Join Clauses */
    null

    Geoff Ingram (guest) wrote:
    : My question
    : ===========
    : exactly what steps do you need follow to take an XML doc,
    store
    : it, and query based on a tag value.
    : The 8i Intermedia text option Reference refers to
    : XLM_SECTION_GROUP feature. However, no examples are given.
    There
    : is no user guide.
    : I searched Oracle's website and found one reference to
    : XML_SECTION_GROUP. The example given is a single row insert
    into
    : a CLOB column with a single pair of tags.
    : This whitepaper gives an example of an XML doc, and a query on
    : it:
    : XML Support in Oracle8i and Beyond
    : November 9, 1998
    : It doesn't list the steps in between storing the doc and
    quering
    : it. This is crucial to the whole thing: does XML_SECTION_GROUP
    : allow all nested tags below the top level to be sectioned and
    : indexed implicitly? Or do you need to tell Oracle about all
    the
    : tags you are interested in, in which case what value is added
    by
    : the XLM_SECTION_GROUP?
    : Does Oracle have some better examples on this?
    : Below is text cut and pasted from the whitepaper.
    : -----------x---------
    : Figure 5: InsuranceClaim Mixes Structured Data and Text
    : <?xml version="1.0"?>
    : <InsuranceClaim>
    : <ClaimID>12345</ClaimID>
    : <LossCategory>7</LossCategory>
    : <Settlements>
    : <Payment>
    : <Payee>Borden Real Estate</Payee>
    : <Date>12-OCT-1998</Date>
    : <Amount>200000</Amount>
    : <Approver>JCOX</Approver>
    : </Payment>
    : </Settlements>
    : <DamageReport>
    : A massive <Cause>Fire</Cause> ravaged the building
    : and
    : <Casualties>12</Casualties> people were killed.
    : Early
    : FBI reports indicate that <Motive>arson</Motive> is
    : suspected.
    : </DamageReport>
    : </InsuranceClaim>
    : Once instances of iFS file types (including XML-based ones)
    are
    : stored in the database, their
    : content can be searched using standard SQL queries, and
    these
    : files can be organized, browsed,
    : and versioned using familiar tools like the Windows
    Explorer.
    : So an insurance agent sees a
    : directory of InsuranceClaim files sheFs recently worked on
    in
    : the field, while an
    : InsuranceClaim-processing application developer can work
    with
    : the information in the
    : InsuranceClaim in any way he needs to.
    : XML-Enabled "Section Searches" in ConText
    : Any XML documents or document fragments saved into "text
    blobs"
    : in the database can be
    : enabled for indexing by Oracle8i InterMediaFs ConText
    : text-search engine. ConText has been
    : enhanced for Oracle8i to allow developers to pinpoint their
    : searches to a particular section of a
    : document, where sections are implicitly defined by the XML
    tags
    : in the document (fragment).
    : Since ConText is seamlessly integrated into the database and
    : the SQL language, developers can
    : use SQL to perform queries that involve both structured data
    : and indexed document fragments.
    : For example, Figure 6 shows the SQL statement you would
    write
    : to search one million
    : Insurance Claims in your database to answer the
    question, "How
    : much money has Jim Cox
    : approved to date in settlement payments for arson-related
    fire
    : claims? "
    : Figure 6: Searching on a Column & Text in XML
    : Sections
    : SELECT SUM(Amount)
    : FROM Claim_Header ch,
    : Claim_Settlements cs,
    : Claim_Settlement_Payments csp
    : WHERE csp.Approver = 'JCOX'
    : AND CONTAINS (DamageReport, 'Arson WITHIN Motive') >
    : 0
    : AND CONTAINS (DamageReport, 'Fire WITHIN Cause' ) >
    : 0
    : AND . . . /* Join Clauses */
    Currently you cannot break apart an arbitrary XML doc and store
    it into the database without using XSLT to create DDL to insert
    it. You can create a schema and have XML be read and written to
    it. Check out the XML SQL Utility available here for download.
    As for the section searching, in 8.1.5 you can only get section
    searching not hierarchical searches. interMedia in this version
    doesn't understand the XML structure. This will come in 8.1.6.
    Oracle XML Team
    http://technet.oracle.com
    Oracle Technology Network
    null

  • 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

  • XML data repository and Search

    I am looking for a tool/technology to stored huge number of XML documents probably as BLOBS and search on them using XPath/XQL
    Is Oracle right technology for it? I heard about Intermedia. Is it a product from Oracle suite which does that.
    Could you please point me to right direction where I can get some more information and some sample code.
    Thanks

    <BLOCKQUOTE><font size="1" face="Verdana, Arial">quote:</font><HR>Originally posted by Steven Muench ([email protected]):
    Vitthal,
    Oracle8i Release 2 and beyond support Intermedia Text searching with automatic support for XML document searching using hierarchical searches.
    The syntax to phrase the queries is presently
    designed after the SQL99 Multimedia facilities and uses a CONTAINS() predicate with a query syntax that is not syntactically XPath, but which can accomplish many of the most useful kinds
    of path queries that XPath lets you do over
    large numbers of documents very fast.
    For example, an XPath query like:
    contains(/Resume/JobSkill,'Java')
    would be:
    CONTAINS( clob_col_with_xml_doc,
    'Java WITHIN JobSkill WITHIN Resume')
    Chapter 13 of "Building Oracle XML Applications" covers searching XML documentst with Intermedia Text, its query syntax, its index setup, and compares and contrasts its functionality with equivalent XPath syntax to achieve the most common types of queries you'll want to do.
    We also have online documentation on Intermedia hosted here on the OTN site, but the documentation is more general and focuses on all of the intermedia text facilities.
    Hope this helps.<HR></BLOCKQUOTE>
    null

  • Storing XML as CLOBs

    Can anyone give me some input on how to
    store XML files as CLOBs in an Oracle database, preferably using jdbc through jsp pages?
    null

    Hello Michael,
    I believe the reference in the demo tutorial is to Insert process (not function). This is probably the process defined on page 8-6, step 4a of the "Create a process to insert information" section.
    Basically you can upload and store files in CLOB. For my self, I only did it with XML files, but I don't see any reason not to do it with other types of files.
    I think that in order to work with non-structured files (like ASCII) you should learn more about Oracle Text. Apex is also using this product. Search this forum for "oracle text" and continue from there.
    Hope this helps,
    Arie.

  • 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

  • XML in CLOB or BFILE

    Could somebody tell me the different between save XML in CLOB and BFILE, addition to generic different between CLOB and BFILE, is there a performance issue?
    Thanks

    CLOB is a fully-updateable, character large object that is stored inside the database. It can be text-indexed using interMedia for document searching.
    BFILE is a readonly pointer to a file on the external file system whose content is not physically stored in the database. It can also be text-indexed for document searching, but it can't be updated.

  • Relational and/or XML DB approach

    Hi:
    I have some (lots of!) questions regarding the proper use of and mixing of relational aspects of Oracle 9i/10g and the XML DB part.
    Assume I have a large amount of free text documents (e.g., emails or something) and those documents contain certain data I am able to parse out (names, addresses, emails addreses, etc.).
    I want to store the entire document as a CLOB or something at some level so that I can do an Oracle Text search on any word or phrase and find the documents that contain it. But I also want to be able to make queries like "return address_info where last_name like '%sm%'" or something. What's the best (for search flexibility, maintainability, loading, etc.) way to do this? I have a situation where sometimes I'll just want to search for keywords or phrases where they occur ANYWHERE in the document, and sometimes I'll want to search for a field with a certain value (e.g. LAST_NAME). And for those regular table type queries, I'll of course want to do joins and oother normal DB things.
    Here are some options I see. Any comments on them? Am I missing anything?:
    1) I can store the structured information in separate tables IN ADDITION to the document as a CLOB. But this means storing certain data twice.
    2) I can try and make the document and XML document with the proper "<LAST_NAME>SMITH</LAST_NAME>" type info in it and possibly use Oracle Text with tag searching??
    a) But won't I pretty much lose the ability to EFFICIENTLY do joins and things like that as I could if that information is in a regular table?
    b) Performance-wise, don't I pretty much need to use an XML Schema backed table? That means I can't just put any old XML in the CLOB, it needs to conform to a certain SCHEMA. When that changes, I have to reload all the XML CLOB data :(
    c) If I have different types of documents and put them each in their own XML Schema based tables, then make Oracle Text indexes on each one, can a query that searches multiple Context Indexes be parallelized efficiently by Oracle?
    3) What are the performance issues (i.e., is it OK or "don't even think about it") of storing the docs as XML CLOBS and creating Object/Relational views for the relational queries of names, addresses, etc.?
    3) What are the ramifications in the different approaches if I have a "large" number of new documents to load each day?

    Hi,
    Possibly you can your XML DB related queries in the OTN XMLDB forum at the following URL for speedier response: XML DB
    -Shefali

  • What's the best way to create and free temporaries for CLOB parameters?

    Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production on Solaris
    I have a procedure calling another procedure with one of the parameters being an IN OUT NOCOPY CLOB.
    I create the temporary CLOB in proc_A, do the call to proc_B and then free the temporary again.
    In proc_B I create a REFCURSOR, and use that with dbms_xmlgen to create XML.
    So the code basically looks like
    CREATE OR REPLACE PROCEDURE client_xml( p_client_id IN            NUMBER
                                           ,p_clob      IN OUT NOCOPY CLOB   ) AS
       v_rc         SYS_REFCURSOR;
       v_queryCtx   dbms_xmlquery.ctxType;
    BEGIN
       OPEN c_rc FOR
          SELECT col1
                ,col2
                ,col3
            FROM clients
           WHERE client_id = p_client_id;
       v_queryCtx := dbms_xmlgen.newContext(v_rc);
       p_clob     := dbms_xmlgen.getXML(v_queryCtx, 0);
    END;
    CREATE OR REPLACE PROCEDURE my_proc AS
       v_clob       CLOB;
       v_client_id  NUMBER;
    BEGIN
       v_client_id := 123456;
       dbms_lob.createTemporary(v_clob, TRUE, dbms_lob.CALL);
       client_xml( p_client_id => v_client_id
                  ,p_clob      => v_clob);
       dbms_lob.freeTemporary(v_clob);
    END;However, I just learned the hard way that IN OUT NOCOPY is only a hint, and that Oracle sometimes creates a local variable for the CLOB anyway.
    A solution is to change the client_xml procedure above to
    CREATE OR REPLACE PROCEDURE client_xml( p_client_id IN            NUMBER
                                           ,p_clob      IN OUT NOCOPY CLOB   ) AS
       v_rc         SYS_REFCURSOR;
       v_queryCtx   dbms_xmlquery.ctxType;
    BEGIN
       IF NOT NVL(dbms_lob.istemporary(p_clob),0) = 1 THEN
          dbms_lob.createTemporary(p_clob, TRUE, dbms_lob.CALL);
       END IF;
       OPEN c_rc FOR
          SELECT col1
                ,col2
                ,col3
            FROM clients
           WHERE client_id = p_client_id;
       v_queryCtx := dbms_xmlgen.newContext(p_refcursor);
       p_clob     := dbms_xmlgen.getXML(v_queryCtx, 0);
    END;My concern is that in case Oracle does create a local variable, 2 temporaries will be created, but there will only be 1 freeTemporary.
    Could this lead to a memory leak?
    Or should I be safe with the solution above because I'm using dbms_lob.CALL?
    Thanks,
    Arnold
    Edited by: Arnold vK on Jan 24, 2012 11:52 AM

    Arnold vK wrote:
    However, I just learned the hard way that IN OUT NOCOPY is only a hint, and that Oracle sometimes creates a local variable for the CLOB anyway.A CLOB variable in called a locator. Just another term for a pointer.
    A CLOB does not exist in local stack space. The variable itself can be TBs in size (max CLOB size is 128TB depending on DB config) - and impossible to create and maintain in the stack. Thus it does not exist in the stack - and is why the PL/SQL CLOB variable is called a locator as it only contains the pointer/address of the CLOB.
    The CLOB itself exists in the database's temporary tablespace - and temporary LOB resource footprint in the database can be viewed via the v$temporary_lobs virtual performance view.
    Passing a CLOB pointer by reference (pointer to a pointer) does not make any sense (as would be the case if the NOCOPY clause was honoured by PL/SQL for a CLOB parameter). It is passed by value instead.
    So when you call a procedure and pass it a CLOB locator, that procedure will be dereferencing that pointer (via DBMS_LOB for example) in order to access its contents.
    Quote from Oracle® Database SecureFiles and Large Objects Developer's Guide
    >
    A LOB instance has a locator and a value. The LOB locator is a reference to where the LOB value is physically stored. The LOB value is the data stored in the LOB.
    When you use a LOB in an operation such as passing a LOB as a parameter, you are actually passing a LOB locator. For the most part, you can work with a LOB instance in your application without being concerned with the semantics of LOB locators. There is no requirement to dereference LOB locators, as is required with pointers in some programming languages.
    >
    The thing to guard against is not freeing CLOBs - the age old issue of not freeing pointers and releasing malloc'ed memory when done. In PL/SQL, there is fairly tight resource protection with the PL/SQL engine automatically releasing local resources when those go out of scope. But a CLOB (like a ref cursor) is not really a local resource. And as in most other programming language, the explicit release/freeing of such a resource is recommended.

  • Parsing xml in clob field remove non utf-8 characters

    hi all,
    i have an issue where a stored procedure runs during a nightly process and parses xml contained in a clob field. There are some records that contain non-utf8(they paste characters from word)characters and therefore the parse fails when using performing an xquery select against the clob field as xmltype. I was wondering if anyone knew of a handy way to handle such a situation? I have looked around a bit and not found anything that seemed tailored to my situation, and I would like something a bit more generic than doing a replace on individual characters that i have found causing issues...thx in advance! -- jp

    Hi,
    Like BluShadow I'm curious to see a test case...
    Depending on the way it's been created, the encoding declared in the XML prolog doesn't necessarily reflects the actual encoding of the content.
    What's your database character set, and version?
    Please also post the error message you get (LPX-00200 probably?).

Maybe you are looking for