ORA-31183 error in XML handling routine after upgrade to 10gr2

Hello,
I have a series of packages that parse XML documents from a staging table, held as XMLType, and breaks it out to populate several relational structures.
These where original developed using 9.2.0.4, and have been used through all patch upgrades to 9i, and on 10gr1 with no issue.
However, we upgraded to 10gr2 this week, and the code has stopped working, returning the following error for all records:-
ORA-31183: Node type document cannot be converted to desired type
ORA-06512: at "XDB.DBMS_XMLDOM", line 1075
ORA-06512: at "XDB.DBMS_XMLDOM", line 1093
ORA-06512: at line 123
I have isolated the error to a call to dbms_xmldom.makeelement. The segment of the code that fails is
v_parser := dbms_xmlparser.newparser;
dbms_xmlparser.parseclob(v_parser, v_mqtl_rec.msg_data.getclobval());
v_dom := dbms_xmlparser.getdocument(v_parser);
dbms_xmlparser.freeparser(v_parser);
v_item_node := dbms_xmldom.makeNode(v_dom);
v_element := dbms_xmldom.makeelement(v_save_callback_node); --ERROR OCCURES HERE
v_nodelist := dbms_xmldom.getchildrenbytagname(v_element,'NotifyCallback');
where v_mqtl_rec.msg_data.getclobval() is the clob from the xmltype, v_parser is dbms_xmlparser.parser, v_item_node is dbms_xmldom.domnode and v_nodelist is dbms_xmldom.domnodelist.
looking at the 10gr2 documntation, I cannot see any changes to this API call.
Any suggestions on why this no longer works?
Regards,
Dave

Figured it out. Turns out the 10gr2 version of DBMS_XMLDOM is a bit stricter on what on can do with various flavours of domnodes.
Just in case anyone else gets a similar error, here's how I resolved it.
I replaced the three lines:-
v_item_node := dbms_xmldom.makeNode(v_dom);
v_element := dbms_xmldom.makeelement(v_save_callback_node); --ERROR OCCURES HERE
v_nodelist := dbms_xmldom.getchildrenbytagname(v_element,'NotifyCallback');
with the following line:-
v_nodelist := dbms_xmldom.getelementsbytagname(v_dom,'NotifyCallback');
Regards,
Dave.

Similar Messages

ORA-29902: error in executing ODCIIndexStart() routine

Hi,
I have a problem with my text mining application.
when I start the classification procedure I get the following errors
Error executing statement: ORA-29902: error in executing ODCIIndexStart() routine
ORA-20000: Oracle Text error:
DRG-50857: oracle error in drcs_query
ORA-06502: PL/SQL: numeric or value error: character to number conversion error
ORA-06512: at "CTXSYS.DRVODM", line 676
ORA-01426: numeric overflow
ORA-06512: at line 1
After closing and restarting the SQL Navigator, most times it works again, but not every time.
Here is the procedure I use:
PROCEDURE sp_classify
IS
vc2_sqlcommand VARCHAR2(1000);
guete DBMS_SQL.number_table;
branche DBMS_SQL.varchar2_table;
BEGIN
vc2_sqlcommand := 'ALTER TABLE ergebnisse MOVE TABLESPACE xxx;
execute IMMEDIATE vc2_sqlcommand;
n_matchscore := 20;
INSERT INTO ergebnisse
SELECT rt.cat_id, pt.produktions_id, match_score(1) AS MatchScore
FROM produktionsdaten pt, trainingsregeln rt
WHERE matches ( rt.rule, pt.geschaeftsgegenstand, 1) > n_matchscore;
COMMIT;
vc2_sqlcommand :=
'CREATE INDEX I_ERG_PRODID ON ERGEBNISSE ' ||
'( PRODUKTIONS_ID ASC ) ' ||
'TABLESPACE XXX' ||
'STORAGE ( INITIAL 64K ' ||
'NEXT 64K ' ||
'PCTINCREASE 0 ' ||
execute IMMEDIATE vc2_sqlcommand;
Please help me
Greetz Steffi Schweppe
Message was edited by:
user634781

I agree with Omar, However if you want to search using special character, you may want to look into the following example. I am not saying this may be a solution for you, however this may give you a start on how to deal with special character in you search.
In our enviroment we have "N" number of Science & Pharmacy & Chemical clients. They need the ability to search using special character for that we have done the following..
begin
select user into v_username from dual;
ctx_ddl.create_preference('orc_CTX_WLPREF', 'BASIC_WORDLIST');
ctx_ddl.set_attribute('orc_CTX_WLPREF','SUBSTRING_INDEX','TRUE');
ctx_ddl.set_attribute('orc_CTX_WLPREF','WILDCARD_MAXTERMS','2559');
ctx_ddl.Create_Preference('orc_LEXER','BASIC_LEXER');
ctx_ddl.Set_Attribute('orc_LEXER', 'index_themes', 'FALSE');
ctx_ddl.set_attribute('orc_LEXER','printjoins','0123456789%,./?;:<>[]{}\|+=-_()*&^$#@!''"%');
end;
And then siply create the index as follow..
create index index_name on activitylog(columnname)
indextype is ctxsys.context
parameters ('Wordlist CYBERLAB_CTX_WLPREF lexer CYBERLAB_LEXER memory 48M');
then I am able to do something like the following..
select count(*) from ACTIVITYLOG where contains (DESCRIPTION, '<%.htm@') > 0;
hope this helps..

SQL Error: ORA-29902: error in executing ODCIIndexStart() routine

I am running a SDO_RELATE operation on 2 geometries from 2 different tables. Spatial indexes are already created and the tables are also versioned.
Below is the spatial meta data for both the geometries in user_sdo_geom_metadata table:
DIMINFO is :
MDSYS.SDO_DIM_ELEMENT(MDSYS.SDO_DIM_ELEMENT(Easting,0,700000,0.001),MDSYS.SDO_DIM_ELEMENT(Northing,0,1300000,0.001),MDSYS.SDO_DIM_ELEMENT(Height,-100,2000,0.001))
SRID is 27700
When I use SDO_RELATE or ADO_ANYINTERACT on both the geometires, i am getting the below error.
Error report:
SQL Error: ORA-29902: error in executing ODCIIndexStart() routine
ORA-13243: specified operator is not supported for 3- or higher-dimensional R-tree
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 333
29902. 00000 - "error in executing ODCIIndexStart() routine"
*Cause: The execution of ODCIIndexStart routine caused an error.
*Action: Examine the error messages produced by the indextype code and
take appropriate action.
Could you please let me know what should be the root cause for this issue?

Hi
Have you checked this posting?
Re: ORA-13243
Luc

ORA-29855: error occured in ODCIINDEXCREATE routine

I'm trying to create a spatial index using Microstation Geographics, but I got error messages.
The first error msg was ORA-29855: error occurred in ODCIINDEXCREATE routine. I think the other messages were also related to that routine.
I tried to create a spatial index (using the same method) in another database. It worked.
I wonder what went wrong. Do I need records in the table to create index?
Thanks!

In the patch readme, I found this:
=======================================================
If you are using an Oracle9i (9.2) preconfigured Standard Edition database, then the database contains the following components that are not supported by the Standard Edition:
Oracle Data Mining
Oracle OLAP Catalog
Oracle OLAP Analytic Workspace
Oracle OLAP API
Spatial
The catpatch.sql script does not run the patch scripts for these components. It sets the component STATUS to "OPTION OFF" in the DBA_REGISTRY view. The original versions of the dictionary objects for the components remain in the database but the catpatch.sql script does not apply the patch to them.
=========================================================
Does it mean it doesn't support Spatial? I'm not sure mine is preconfigured Standard Edition database though.

ORA-20001: ORA-29902: error in executing ODCIIndexStart() routine

Hi, everyone!
I have an error as follow:
ORA-20001: ORA-29902: error in executing ODCIIndexStart() routine
ORA-06553: PLS-123: program too large
I can get the sql where the procedure through the error, and execute the sql in sqlplus, no error. Does anyone have experience with the error? or have some direction to solve problem? thank you!
My oracle version is 9.2.0.8.0 and sdo version is 9.2.0.8.0, too.

I agree with Omar, However if you want to search using special character, you may want to look into the following example. I am not saying this may be a solution for you, however this may give you a start on how to deal with special character in you search.
In our enviroment we have "N" number of Science & Pharmacy & Chemical clients. They need the ability to search using special character for that we have done the following..
begin
select user into v_username from dual;
ctx_ddl.create_preference('orc_CTX_WLPREF', 'BASIC_WORDLIST');
ctx_ddl.set_attribute('orc_CTX_WLPREF','SUBSTRING_INDEX','TRUE');
ctx_ddl.set_attribute('orc_CTX_WLPREF','WILDCARD_MAXTERMS','2559');
ctx_ddl.Create_Preference('orc_LEXER','BASIC_LEXER');
ctx_ddl.Set_Attribute('orc_LEXER', 'index_themes', 'FALSE');
ctx_ddl.set_attribute('orc_LEXER','printjoins','0123456789%,./?;:<>[]{}\|+=-_()*&^$#@!''"%');
end;
And then siply create the index as follow..
create index index_name on activitylog(columnname)
indextype is ctxsys.context
parameters ('Wordlist CYBERLAB_CTX_WLPREF lexer CYBERLAB_LEXER memory 48M');
then I am able to do something like the following..
select count(*) from ACTIVITYLOG where contains (DESCRIPTION, '<%.htm@') > 0;
hope this helps..

ORA-29902: error in executing ODCIIndexStart() routine ORA-06502: PL/SQL: n

I'm trying a simple spatial query and this does not work:
select count(1) from will w,
t_line_sdo t
where w.ID = 2 --
and SDO_relate(T.sdo, W.sdo,
'mask=anyinteract querytype=WINDOW')= 'TRUE'
t_line_sdo is indexed on sdo column.
will is indexed on sdo column
I get an error in executing ODCIIndexStart() routine.
But this works:
select count(1) from will w,
t_line_sdo t
where w.ID = 2 --
and SDO_filter(T.sdo, W.sdo,
'querytype=WINDOW')= 'TRUE'
-puzzled

Hi Will,
No luck reproducing the error on my 9.2.0.1 system.
I slightly changed the user_sdo_geom_metadata entries to set the coordinate system bounds/tolerance to:
-180,180,0.5
-90,90,0.5
but I don't think those would have been the difference.
Another change I made was to the queries to use t_line_sdo instead of t_line.
If I was writing the query I might make one slight modification though - I'd use the /*+ ordered */ hint:
select /*+ ordered */ count(1) ALBERTA from will w,
t_line_sdo t
where w.CAN_BOR_35_ID = 2
and SDO_RELATE( t.sdo, w.sdo,
'mask=anyinteract querytype=WINDOW')= 'TRUE';
Perhaps this will help you.
Here is what I did:
CREATE TABLE WILL
CAN_BOR_35_ID NUMBER (17) NOT NULL,
BOR_CODE VARCHAR2(5),
SDO MDSYS.SDO_GEOMETRY NOT NULL
--Here's my insert:
INSERT INTO WILL
VALUES ( 2, 'ALBT', MDSYS.SDO_GEOMETRY(
2003, -- 2-dimensional polygon
8307, -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system
NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),
MDSYS.SDO_ORDINATE_ARRAY( -114.05013, 49.00081, -- ALBT1
-109.98920, 48.98902, -- SASK1
-110.00531, 49.50556, -- SASK6
-114.59275, 49.50253, -- ALBT2
-114.05013, 49.00081) -- ALBT1 -- CLOSE THE LOOP
COMMIT;
-- of course I did the insert into the metadata table...
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'WILL',
'SDO',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', -180, 180, 0.5),
MDSYS.SDO_DIM_ELEMENT('Y', -90, 90, 0.5)),
8307 -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system
INSERT INTO USER_SDO_GEOM_METADATA
VALUES (
'T_LINE_SDO',
'SDO',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('X', -180, 180, 0.5),
MDSYS.SDO_DIM_ELEMENT('Y', -90, 90, 0.5)),
8307 -- SRID for 'Longitude / Latitude (WGS 84)' coordinate system
COMMIT;
CREATE INDEX IDX_WILL
ON WILL (SDO)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
--And I did the validate:
select T.BOR_CODE , SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
(T.SDO, 0.5)
from WILL T
-- Script to create t_line_sdo:
CREATE TABLE t_line_sdo
(life_id NUMBER(17,0) NOT NULL,
feat_code NUMBER(4,0),
sdo MDSYS.SDO_GEOMETRY)
INSERT INTO t_line_sdo
VALUES
(1994622361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.08714, 49.14799, -112.08772, 49.14847, -112.08851, 49.1492,
-112.08879, 49.14954, -112.08894, 49.14977, -112.0899, 49.15134, -112.09043, 49.15218)))
INSERT INTO t_line_sdo
VALUES
(1994632361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.09043, 49.15218, -112.09117, 49.15336, -112.09239, 49.15544,
-112.09338, 49.15718, -112.09408, 49.15835, -112.09495, 49.15992, -112.09542, 49.16066,
-112.09579, 49.16131, -112.09624, 49.16224, -112.09642, 49.16285, -112.09654, 49.16332,
-112.09657, 49.16389, -112.09658, 49.16468, -112.0965, 49.16529, -112.09612, 49.16633,
-112.09594, 49.16677, -112.0945, 49.16904, -112.09403, 49.16984, -112.09326, 49.17102,
-112.09292, 49.17165, -112.09266, 49.17218, -112.09256, 49.1726, -112.09252, 49.17298,
-112.0925, 49.17337, -112.09256, 49.17385, -112.09265, 49.17419)) )
INSERT INTO t_line_sdo
VALUES
(1994642361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.09265, 49.17419, -112.09277, 49.17457, -112.09306, 49.1751,
-112.09385, 49.17636, -112.09511, 49.17845, -112.09728, 49.18187, -112.09832, 49.18355,
-112.09864, 49.18412, -112.09897, 49.18462, -112.09921, 49.18493, -112.09961, 49.18533,
-112.10004, 49.18567, -112.10053, 49.18602, -112.10302, 49.18744, -112.11002, 49.19128,
-112.1151, 49.1941, -112.11592, 49.1946, -112.1164, 49.19497, -112.11687, 49.19545,
-112.11749, 49.19642, -112.11898, 49.20042, -112.11989, 49.20288)))
INSERT INTO t_line_sdo
VALUES
(1994712361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.06171, 49.1155, -112.0626, 49.11626, -112.06361, 49.11717,
-112.0661, 49.11924, -112.0673, 49.12028, -112.06886, 49.12156, -112.07009, 49.12263,
-112.07084, 49.12319, -112.07145, 49.12385, -112.07233, 49.12489, -112.07314, 49.12607,
-112.07415, 49.12744, -112.07484, 49.12843, -112.07534, 49.12904, -112.07553, 49.12938,
-112.07574, 49.12968, -112.07603, 49.13043, -112.07624, 49.13107, -112.07832, 49.13632)))
INSERT INTO t_line_sdo
VALUES
(1994722361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.06171, 49.1155, -112.0626, 49.11626, -112.06361, 49.11717,
-112.0661, 49.11924, -112.0673, 49.12028, -112.06886, 49.12156, -112.07009, 49.12263,
-112.07084, 49.12319, -112.07145, 49.12385, -112.07233, 49.12489, -112.07314, 49.12607,
-112.07415, 49.12744, -112.07484, 49.12843, -112.07534, 49.12904, -112.07553, 49.12938,
-112.07574, 49.12968, -112.07603, 49.13043, -112.07624, 49.13107, -112.07832, 49.13632)))
INSERT INTO t_line_sdo
VALUES
(1994852361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.07832, 49.13632, -112.07849, 49.13678, -112.07912, 49.13847,
-112.08024, 49.14133, -112.0806, 49.14208, -112.0809, 49.14257, -112.08126, 49.14305,
-112.08219, 49.14393, -112.0826, 49.14434, -112.08341, 49.14508, -112.08397, 49.14555,
-112.08591, 49.14708, -112.08714, 49.14799)))
INSERT INTO t_line_sdo
VALUES
(2681482361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.05406, 49.10917, -112.05521, 49.11004, -112.0561, 49.11082)) )
INSERT INTO t_line_sdo
VALUES
(2681492361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.06313, 49.11545, -112.06171, 49.1155)))
INSERT INTO t_line_sdo
VALUES
(2681502361001,4110,
MDSYS.SDO_GEOMETRY(2002, 8307, NULL,
MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1),
MDSYS.SDO_ORDINATE_ARRAY(-112.0561, 49.11082, -112.05787, 49.11233, -112.05916, 49.11338,
-112.06171, 49.1155)))
commit
create index IDX_T_LINE_SDO on t_line_sdo (sdo)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
--And I did the validate:
select T.LIFE_ID , SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
(T.SDO, 0.5)
from T_LINE_SDO T
-- Both of these work
select count(1) ALBERTA from will w,
t_line_sdo t
where w.CAN_BOR_35_ID = 2
and SDO_RELATE( t.sdo, w.sdo,
'mask=anyinteract querytype=WINDOW')= 'TRUE';
-- Works (because it's doing a full table scan???)
select count(1) ALBERTA from will w,
t_line_sdo t
where w.CAN_BOR_35_ID = 2
and SDO_RELATE( w.sdo, t.sdo,
'mask=anyinteract querytype=WINDOW')= 'TRUE';

Oracle error "No message file for" after Upgrade to 10.2.0.5

After upgrade from 9.2.0.8 to 10.2.0.5 i get the following error "No message file for"
(with both Users sidadm and orasid)
Platform AIX 64 bit
The installation und Upgrade with dbua works fine.
DB and SAP runs after the Upgrade.
then I tried
SQL> select xx from v$log;
select xx from v$log
ERROR at line 1:
ORA-00904: Message 904 not found; No message file for produstyle='font-
family:courier' ct=RDBMS,
facility=ORA; arguments: ["XX"]
The Environment is correct,
ORACLE_HOME,ORACLE_SID,PATH,LIBPATH have right Values.
I cant find any failure in Configuration or Install Logs.
So i tried the following:
Copy the complete Directorie /oracle/SID/102_64/rdbms/msg from a
10.2.0.4 Oracle Installation to the 10.2.0.5 home.
the result ist that the Messagefile could be read by Oracle an i get
the ORA-00904
Here the same Query:
SQL> select xx from v$log;
select xx from v$log
ERROR at line 1:
ORA-00904: "XX": invalid identifier
So I do the same procedure with an other System.
I detect:
the Patch 9952230 (SAP_102051_201011/9952230) delivers
both Message Files oraus.msg and oraus.msb which caused the problem.
Has anyone the same Problem?
Are there any other Impacts with wrong Message Files .
I raised a OSS Call, but no answer till today.
best regards
Uwe

I could not find anything is sap notes, but oracle recommends to update binary file oraus.msb in $ORACLE_HOME/rdbms/mesg
Download link:
https://updates.oracle.com/ARULink/PatchDetails/process_form?patch_num=10235783
You can find more details also in:
https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=10235783.8
https://support.oracle.com/CSP/main/article?cmd=show&type=BUG&id=10235783
The problem with this solution. It is not officially released by SAP.

Error while executing SSIS Package after upgrading the Oracle Client

Hello,
I am running to the below error after we upgraded the Oracle client to 11g from 10g. The source of the Data is Oracle database . Looked online but each error is pointing towards different route, Confused here any help is very much appreciated. Have to say
I am not a pro with SSIS.
SSIS package "Bentek_ISO_Package (2).dtsx" starting.
Information: 0x4004300A at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: Validation phase is beginning.
Information: 0x4004300A at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: Validation phase is beginning.
Warning: 0x80049304 at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: Warning: Could not open global shared memory to communicate with performance DLL; data flow performance counters are not available. To resolve, run this package as an administrator,
or on the system's console.
Information: 0x40043006 at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: Prepare for Execute phase is beginning.
Information: 0x40043007 at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: Pre-Execute phase is beginning.
Error: 0xC0202009 at Temp_tbl Injection Data Flow Task, OLE DB Source [1]: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80040E14.
An OLE DB record is available. Source: "OraOLEDB" Hresult: 0x80040E14 Description: "ORA-12801: error signaled in parallel query server P183, instance *****:qrmgmt2 (2)
ORA-01861: literal does not match format string".
An OLE DB record is available. Source: "OraOLEDB" Hresult: 0x80004005 Description: "ORA-12801: error signaled in parallel query server P183, instance ****:qrmgmt2 (2)
ORA-01861: literal does not match format string".
Error: 0xC004701A at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: component "OLE DB Source" (1) failed the pre-execute phase and returned error code 0xC0202009.
Information: 0x4004300B at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: "component "OLE DB Destination" (52)" wrote 0 rows.
Information: 0x40043009 at Temp_tbl Injection Data Flow Task, SSIS.Pipeline: Cleanup phase is beginning.
Task failed: Temp_tbl Injection Data Flow Task
Warning: 0x80019002 at *******: SSIS Warning Code DTS_W_MAXIMUMERRORCOUNTREACHED. The Execution method succeeded, but the number of errors raised (2) reached the maximum allowed (1); resulting in failure. This occurs when the number of errors reaches
the number specified in MaximumErrorCount. Change the MaximumErrorCount or fix the errors.
SSIS package "****** (2).dtsx" finished: Failure.

Do you have any Date conversion functions in your Oracle datetime fields? I did run into a similar issue when we upgraded the oracle client and the provider started to decipher the metadata of the date columns. The SSIS metadata conversion for the date
columns yielded dates that were not valid. I had to update my queries to use the TO_CHAR conversion to bring it out as a string and then save it to the date field.
TO_CHAR (DATE, 'MM/DD/YYYY HH24:MI:SS')
Regards, Dinesh

Errors with with portal providers after upgrading database to 10.2.0.3

Hello,
We are receiving errors when trying to do anything with providers that we have created in Portal. The problems have started after upgrading the underlying database from 10.1.0.4 to 10.2.0.3 on RH Linux 3.0. Our version of Portal is 10.1.2.0.1 and is running on SUSE 9.
If we try to select the 'Actions' button for any of the portlets that include custom providers, we get the following errors:
Internal error (WWC-00006)
An unexpected error occurred: User-Defined Exception (WWC-43000)
An unexpected error occurred: User-Defined Exception (WWC-43000)
The provider URL specified may be wrong or the provider is not running. (WWC-43176)
Likewise, if we try to deregister/reregister one of the providers, it asks us the following questions:
1. Do you want to deregister provider "Provider Name"?
Deregistering a provider removes it from the system. All usages of portlets from that provider will be deleted.
********We answer 'Yes' to this
2. The provider could not be contacted, do you still want to delete provider "Provider Name"?
The provider could not be contacted and its deregistration function was not initiated. Deleting the provider will remove it from the portal. Additional action may be necessary by the provider to remedy the failure to call its deregistration function.
********Again we answer 'Yes' to this. After answering yes, we get the following error:
Internal error (WWC-00006)
Unexpected error - ORA-04091: table PORTAL.WWPRO_PORTLET_METADATA$ is mutating, trigger/function may not see it
ORA-06512: at "PORTAL.WWUTL_EVENT", line 173
ORA-06512: at "PORTAL.WWPRO_PMR_NLS_EVENT_TRG", line 23
ORA-04088: error during execution of trigger 'PORTAL.WWPRO_PMR_NLS_EVENT_TRG' (WWC-35000)
All of the providers (4 of them) we have manually added (not seeded) receive the above errors, however 3 out of the 4 seem to function fine in the portal (if we don't try to modify). The fourth calls an external e-mail application, and this is not working.
The database upgrade has seemed to cause this issue, but I'm not sure why. Do we need to somehow upgrade these providers? Any help would be appreciated!
Thanks,
Rick

Hi
This is AIX 5L specific problem.
Yo should modify 2 LINES of $CRS_HOME/bin/racgvip file
FROM :
O1=`$NETSTAT -n -I $IF | $AWK "{ if (/^$_IF/) {print \\$5; exit}}"`
O2=`$NETSTAT -n -I $IF | $AWK "{ if (/^$_IF/) {print \\$5; exit}}"`
TO:
O1=`$NETSTAT -n -I $IF | $AWK "{ if (/^$_IF/) {print \\$6; exit}}"`
O2=`$NETSTAT -n -I $IF | $AWK "{ if (/^$_IF/) {print \\$6; exit}}"`
briefly $5 --> $6
this is because of
#/usr/bin/netstat -f inet -n -I en1
command returns extra column ( ZoneID ) which RAC software is unaware
#/usr/bin/netstat -f inet -n -I en1
Name Mtu Network Address ZoneID Ipkts Ierrs Opkts Oerrs Coll
en1 1500 link#3 0.21.5e.34.55.bc - 35645 0 16801 3 0
en1 1500 10.46.180 10.46.180.52 - 35645 0 16801 3 0
for details goto
http://www.ubtools.com/jira/browse/QA-48
This solution stated by Danisment Gazi Unal.
Gokhan Tercan
ORacle DBA
Edited by: GokhanTercan on 19.Eki.2009 08:06

Error AA662 in Asset accounting after upgrade to ECC 6

Hi,
After upgrade to ECC6 from R3 Enterprise, when we try to browse an asset, using transaction code AW01N, and go to posted values/Comparisons tab we get the following error:
SYST: You cannot change the depreciation periods
     Message no. AA662
Asset affected: 000000003983-0000
Diagnosis
    Processing terminated because the number of depreciation periods in company code 1100 has been changed. However, you cannot change the number of
    periods in your live (productive) system.
Procedure
    Change the depreciation periods back to the original value in company code 1100. The number of depreciation periods is determined by the fiscal year version and the use of half-periods. At least one of these parameters was changed.
     If you want to change your system so that you can now work with half-periods, you have to use depreciation keys with time-dependent period control in that company code.
    If you need to make general changes to the number of periods for calculating depreciation per fiscal year, you will have to consult your system administrator.
We were not getting this error in R3 enterprise. We have tried implementing sap note 1009699 but it does not resolve the issue. What we observed is, AA662 occurs if you change the number of period in the fiscal year version or the use of half-periods, after you have already posted to assets. The most common cause is a different value in field ANLB-PERFY which is the number of periods in the fiscal year. If the number entered here does not correspond to the number of posting periods of the fiscal year used, the system raises error AA662 (except for none posted areas for which ANLB-PERFY = 000 or areas with depreciation to the date for which ANLB-PERFY = 365). For us there are many assets with ANLB-PERFY=24.
Is there a way to fix this problem by some config change or data fix. If any of you have come across a similar issue or have any insights on the same, please respond back.
Regards,
Milan
([email protected])

Hi All,
I could not find any solution to fix this in new depreciation calculation method. I also did not get any help from SAP or SDN. So, we decided to switch back to the old calculation method.
There are 3 ways of implementing the old calculation.
1. SAP Note 984161 : Code change at ABAP level.
2. User Level : By setting the user parameter FAA_DC_SWITCH to OLD
3. By default Config : If we make an entry in V_TABWD_VID in SM30 and create a new entry with Acct. Transaction ID to 'AMBUAFAR000000000000', It should use old calculation method.
Thanks,
Milan
+1-310-691-3978
+91-994-571-5063

ERROR MESSAGE IN PPOME TCODE AFTER UPGRADE TO ECC 6.0

Hi Experts,
I have a question.
Recently our system went for upgrade and during testing phase we have found one issue.
Error message is appearing in PPOME transactio code after upgrade to ECC 6.0
The screen is getting defaulted to Budget section and unable to find the subtype as there are no subtypes available there and showing error message as "Fill in all required fields".
Please let me know your solution on this.
Regards,
Sekhar.

Hi,
- you can deactivate the budget tab in the IMG-activity 'Hide/Show Tab Page'
(SIMG_CFMENUOHP1HFW20 alternatively use SM30 on view 'T77OCTABUS')
1. Create new entries for the following KEY:
a) Scenario OME0
b) Object type 'P', 'O', 'S'
c) Tab Page 'PBC_ORIG'
2. for each of this entries, set the 'Exclude Tab Page'-Flag.
- in case you do not want to deactivate the Budget tab:
The error occurs due to missing entries for subtypes in table T778U
for infotype 1516.
Please maintain the according subtyes you want to use if you create a
budget.
Regards,
Ana

IDOC Syntax Error E0072 with status 26 after upgrade to ECC6.0

Hi
We have upgraded SAP R/3 from 4.6C to ECC6.0. After upgrade, when we create PO and output EDI, we are seeing this IDOC syntax error E0072 for Mandatory Segment E1EDK01. In 4.6C it was working fine with no issues, only after upgrade this problem started. It says E1EDK01 is missing which is mandatory. We are using basic type ORDERS01 with no extensions. When we see WE30 it looks fine, WE20 settings looks fine.
Order of the segments got scrambled in upgraded version. First segment is E1EDP19001, this is supposed to be under E1EDP01 segment. There are two E1EDP19001 segments created but there were no sub segments to E1EDP01.
Any help in this regard is highly appreciated.
Thanks
Pandiri

User Exit activation and fixing the issue in user exit fixed this issue.

Error UCD1038 regarding Movement Type after upgrade

During testing for the BW upgrade and implementation of BPC, the SEM-BCS data collection resulted in an unexpected and unnecessary error: Maximum selection does not contain value 600 of subassignment Movement Type; Message no. UCD1038.
Both before and after upgrade the task log shows Source records with the movement type but with no value in transaction currency, local currency and group currency. But after the upgrade these records also appear in the Target log where there had previously been excluded.
SAP Note 1583871 was implemented without any noticeable improvement.
The SEM-BCS data collection uses load-from-datastream with a source databasis that is virtual cube reading data from the ECC leading ledger. The source data is unchanged and before the upgrade the error did not occur.
The SAP components before the upgrade are:
SAP_ABA        700       0021 SAPKA70021     Cross-Application Component
SAP_BASIS      700       0021 SAPKB70021     SAP Basis Component
PI_BASIS       2006_1_7000011 SAPKIPYM11     Basis Plug-In (PI_BASIS) 2006_1_700
ST-PI          2008_1_7000004 SAPKITLRD4     SAP Solution Tools Plug-In
SAP_BW         700       0023 SAPKW70023     SAP NetWeaver BI 7.0
FINBASIS       603       0003 SAPK-60303INFINFINBASIS 603
BI_CONT        703       0016 SAPKIBIIQ6     Business Intelligence Content
SEM-BW         603       0003 SAPK-60303INSEMSEM-BW 603
ST-A/PI 01N_700BCO 0000      - Servicetools for other App./Netweaver 04
The SAP components after the upgrade are:
SAP_ABA        701       0007 SAPKA70107     Cross-Application Component
SAP_BASIS      701       0007 SAPKB70107     SAP Basis Component
PI_BASIS       701       0007 SAPK-70107INPIBBasis Plug-In
ST-PI          2008_1_7000004 SAPKITLRD4     SAP Solution Tools Plug-In
SAP_BS_FND     701       0007 SAPK-70107INSAPSAP Business Suite Foundation
SAP_BW         701       0007 SAPKW70107     SAP Business Warehouse
FINBASIS       604       0007 SAPK-60407INFINFINBASIS
BI_CONT        704       0007 SAPK-70407INBICBusiness Intelligence Content
CPMBPC 750 0006 SAPK-75006INCPMBPC CPM Business Planning and Consolidation
SEM-BW 604 0007 SAPK-60407INSEMBW SEM-BW
ST-A/PI 01N_700BCO 0000      - Servicetools for other App./Netweaver 04
Any help resolving this are greatly appreciated.

Hi Dan,
This can be resolved by activating modification as suggested in the note 1074599.
Suresh Jayanthi.

Meta dates in AlbumData.xml (date problems after upgrade)

HI folk,
Further to my post earlier today about the date mashup after upgrading, I was wondering if a [careful!] edit of the AlbumData.xml file might help.
If I knew what these fields meant I might be able to work out what to do...
<key>DateAsTimerInterval</key>
<real>9850139.000000</real>
<key>ModDateAsTimerInterval</key>
<real>206299947.507982</real>
<key>MetaModDateAsTimerInterval</key>
<real>206299831.664670</real>
Which one (if any of these) does iPhoto use when deciding what order to display the photos in? And what are the numbers? Seconds since 1984? Picoseconds since the Woz left the company? Curious minds want to know.
And yes, I'd use a backup for experimentation.
Rob

Rob,
That timestamp is probably based on the [Unix Epoch|http://en.wikipedia.org/wiki/Unix_time], the basis for almost all time stamps in programs based on Unix and/or the C programming language. If those dates are in fact based on the Unix epoch, they are based on the number of seconds since Jan1, 1970.
Sometimes such dates are represented as integers (like DateAsTimerInterval seems to be) and sometimes they are represented as floating point numbers (like the other two) in an attempt to circumvent the Year 2038 problem.
You may find this useful: [http://www.unixtimestamp.com>
Personally, I would love to find out how your experimentation goes - what fails and what works; if you have to go through any hoops to get iPhoto to recognize your changes; if exporting a photo changes its EXIF timestamps after you play with the XML file, etc.
nathan

XML load error - when moving table data after upgrade

Greetings:
Background:
Previously in our 2.2 instance, we would use the Data Load/Unload feature of APEX to move data in the form of XML from instance 1 to instance 2. This woks well because it moves images also (BLOB)
What Changed:
Recently we did the upgrade to APEX 3.0. The tool is working well, but we are having issues uploading XML data in the same manner we used to. The process wizard works up until time for execution.. the following error message is seen.
XML load error.
Return to application.
Assumption:
I do not believe this is an XML file issues because the file I am testing the process with is from the EMP table, and is from the UNLOAD option on the same DB and SCHEMA.. (testing is unloading the data, than re-loading the same data to the same place)
Internally some permissions or something internal must be missing.
Assistance or suggestions on where to look is greatly appreciated.
Regards,
Tim

Tim,
Sorry for the delay - that silly day job keeps getting in the way.
Here is a small procedure you could use to take the XML data file format exported from Application Express and import into your table. This uses the Java-dependent DBMS_XMLSAVE package, which avoids the issue mentioned above.
create or replace procedure load_xml(
    p_clob   in clob,
    p_schema in varchar2,
    p_table in varchar2 )
is
    l_insCtx dbms_xmlsave.ctxType;
    l_rows   number;
begin
    l_insCtx := dbms_xmlsave.newContext(p_schema || '.' || p_table);
    dbms_xmlsave.setDateFormat(l_insCtx,'yyyy-MM-dd''T''HH:mm:ss.SSS');
    l_rows := dbms_xmlsave.insertXML( l_insCtx, p_clob);
    dbms_xmlsave.closeContext(l_insCtx);
end load_xml;I then ran the following quick test on apex.oracle.com just for verification.
declare
    l_xml varchar2(32000);
begin
    l_xml := '<?xml version="1.0"?>
<ROWSET>
<ROW>
<ID>11645117496276327</ID>
<FLOW_ID>30072</FLOW_ID>
<NAME>F11645117496276327/no_image_found.gif</NAME>
<FILENAME>no_image_found.gif</FILENAME>
<MIME_TYPE>image/gif</MIME_TYPE>
<CREATED_BY>JOEL</CREATED_BY>
<CREATED_ON>2007-03-14T05:06:38.000</CREATED_ON>
<BLOB_CONTENT>474946383961C800...(data removed for this example)...41000003B</BLOB_CONTENT>
</ROW>
</ROWSET>';
    load_xml( l_xml, 'MY_DB_USER', 'MY_APEX_FILES' );
end;It's now simply a matter of how you get your XML file(s) into a CLOB to call this procedure. The options include:
1) Just pass in a VARCHAR2 as I did in the example above, which would limit you to roughly 32K.
2) You could use DBMS_LOB.LOADCLOBFROMFILE to read it from the database server filesystem.
3) You could upload the file via an APEX application (or some other means within APEX), you could convert the BLOB to a CLOB, and then call this procedure. If you need help with this method, let me know.
Don't forget - as yet another alternative, you could always contact Oracle Support to see what could be done about that underlying database bug.
I hope this helps.
Joel

ORA-31183 error in XML handling routine after upgrade to 10gr2

Similar Messages

Maybe you are looking for