How to get rid of "ORA-22881: dangling REF" error on :new.OBJECT_VALUE?

Question

Hi,
I'm having trouble with a "ORA-22881: dangling REF" error against :new.OBJECT_VALUE when a trigger executes.
Here is the initial trigger:
create or replace TRIGGER "CSHEET_UPDATE"
BEFORE UPDATE ON "CSHEET" FOR EACH ROW
BEGIN
SELECT
updateXML(
:new.OBJECT_VALUE,
'/Csheet/METADATA/MODIFIED_DATE/text()', to_char(SYSDATE, 'YYYY-MM-DD') || 'T' || to_char(SYSDATE, 'HH:MI:SS')
INTO :new.OBJECT_VALUE FROM dual;
END;
And this is the error I get with even a simple UPDATE:
BEGIN
UPDATE CSHEET SET OBJECT_VALUE = OBJECT_VALUE WHERE rownum = 1;
COMMIT;
END;
Error report:
ORA-22881: dangling REF
ORA-06512: at "LNC.CSHEET_UPDATE", line 5
ORA-04088: error during execution of trigger 'LNC.CSHEET_UPDATE'
ORA-06512: at line 2
22881. 00000 - "dangling REF"
*Cause:    The object corresponding to the REF that was accessed does not
exist.
*Action:   Ensure that the REF value is pointing to an existing object.
However, if I add a schemavalidate() call at the beginning of the trigger then the error disappears.
New trigger:
create or replace TRIGGER "CSHEET_UPDATE"
BEFORE UPDATE ON "CSHEET" FOR EACH ROW
BEGIN
:new.OBJECT_VALUE.schemavalidate();
SELECT
updateXML(
:new.OBJECT_VALUE,
'/Csheet/METADATA/MODIFIED_DATE/text()', to_char(SYSDATE, 'YYYY-MM-DD') || 'T' || to_char(SYSDATE, 'HH:MI:SS')
INTO :new.OBJECT_VALUE FROM dual;
END;
Is there another way, besides using ":new.OBJECT_VALUE.schemavalidate();", to correct the :new.OBJECT_VALUE dangling REF issue?
Thanks
Keith

Answer 1

Hi Marco,
This is my version info:
Oracle Database 11g Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE 11.1.0.6.0 Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
CSHEET is indeed object relational storage.
BEGIN
DBMS_XMLSCHEMA.REGISTERSCHEMA(
schemaurl => 'CSheet.xsd',
schemadoc => sys.UriFactory.getUri('/public/Schemas/CSheet.xsd'),
local => TRUE,
gentypes => TRUE,
genbean => FALSE,
gentables => TRUE,
force => FALSE,
owner => 'LNC',
enablehierarchy => DBMS_XMLSCHEMA.ENABLE_HIERARCHY_NONE
END;
The only "unusual" aspect of it is that it does some out-of-line storage, has a primary key assigned internally, and specifies a couple of unique restrictions:
Snippets from the schema:
<xs:element name="Csheet" xdb:defaultTable="CSHEET" xdb:columnProps="CONSTRAINT CSHEET_pkey PRIMARY KEY (XMLDATA.UCN)">
<xs:element name="LEGISLATION" maxOccurs="unbounded" xdb:SQLInline="false" xdb:defaultTable="CSHEET_LEGISLATION">
<xs:complexType>
<xs:sequence>
<xs:choice>
<xs:sequence>
<xs:element name="NAME" type="reasonable_data_T"/>
<xs:element name="CITATION" minOccurs="0" type="CITATION_T"/>
</xs:sequence>
<xs:element name="CITATION" type="CITATION_T"/>
</xs:choice>
<xs:element name="REFERENCES">
<xs:complexType>
<xs:sequence>
<xs:element name="REFERENCE" maxOccurs="unbounded" xdb:SQLInline="false" xdb:defaultTable="CSHEET_REFERENCES">
<xs:complexType>
<xs:sequence>
<xs:unique name="unique_pinpoints">
<xs:selector xpath="REFERENCE"/>
<xs:field xpath="PINPOINT"/>
</xs:unique>
<xs:unique name="unique_legislation">
<xs:selector xpath="LEGISLATION"/>
<xs:field xpath="CITATION"/>
</xs:unique>
And I rename and scope the REF tables:
DECLARE
gen_name VARCHAR2 (4000);
BEGIN
SELECT TABLE_NAME INTO gen_name FROM USER_NESTED_TABLES
WHERE PARENT_TABLE_NAME = 'CSHEET';
EXECUTE IMMEDIATE 'RENAME "' || gen_name || '"TO CSHEET_LEG_V';
SELECT TABLE_NAME INTO gen_name FROM USER_NESTED_TABLES
WHERE PARENT_TABLE_NAME = 'CSHEET_LEGISLATION';
EXECUTE IMMEDIATE 'RENAME "' || gen_name || '"TO CSHEET_REF_V';
END;
ALTER TABLE CSHEET_LEG_V ADD SCOPE FOR (COLUMN_VALUE) IS CSHEET_LEGISLATION;
ALTER TABLE CSHEET_REF_V ADD SCOPE FOR (COLUMN_VALUE) IS CSHEET_REFERENCES;
Nothing really non-standard and everything works just fine...except I HAVE to schemavalidate() to undangle my REF :( .
I don't even understand where the REF is coming from since it was my understanding that OBJECT_VALUE was considered an XMLType. Could it have something to do with the out-of-line tables?
Thanks
Keith