Abap insert into info cube results in ORA 14400

Question

Hi friends,
in principle the situation is as following:
we have 2 cubes which are identically in design, in the number of info objects etc.
now we have the following code here:                                                                   
* Dann aus Quelltabellen kopieren
* (Fakten zuletzt wegen Fremdschlüsselbez. zu Dim.)
  CHECK P_KOP IS NOT INITIAL.
  COMMIT WORK.
  SELECT * FROM /BIC/DZHW_CUBE1P.
    CHECK /BIC/DZHW_CUBE1P-DIMID <> 0.
    MOVE-CORRESPONDING /BIC/DZHW_CUBE1P TO /BIC/DZHW_CUBE2P.
    INSERT /BIC/DZHW_CUBE2P.
  ENDSELECT.
  SELECT * FROM /BIC/DZHW_CUBE1T.
    CHECK /BIC/DZHW_CUBE1T-DIMID <> 0.
    MOVE-CORRESPONDING /BIC/DZHW_CUBE1T TO /BIC/DZHW_CUBE2T.
    INSERT /BIC/DZHW_CUBE2T.
  ENDSELECT.
  SELECT * FROM /BIC/DZHW_CUBE1U.
    CHECK /BIC/DZHW_CUBE1U-DIMID <> 0.
    MOVE-CORRESPONDING /BIC/DZHW_CUBE1U TO /BIC/DZHW_CUBE2U.
    INSERT /BIC/DZHW_CUBE2U.
  ENDSELECT.
  SELECT * FROM /BIC/DZHW_CUBE11.
    CHECK /BIC/DZHW_CUBE11-DIMID <> 0.
    MOVE-CORRESPONDING /BIC/DZHW_CUBE11 TO /BIC/DZHW_CUBE21.
    INSERT /BIC/DZHW_CUBE21.
  ENDSELECT.
  COMMIT WORK.
  SELECT * FROM /BIC/FZHW_CUBE1.
    /BIC/FZHW_CUBE2-KEY_ZHW_CUBE2P = /BIC/FZHW_CUBE1-KEY_ZHW_CUBE1P.
    /BIC/FZHW_CUBE2-KEY_ZHW_CUBE2T = /BIC/FZHW_CUBE1-KEY_ZHW_CUBE1T.
    /BIC/FZHW_CUBE2-KEY_ZHW_CUBE2U = /BIC/FZHW_CUBE1-KEY_ZHW_CUBE1U.
    /BIC/FZHW_CUBE2-KEY_ZHW_CUBE21 = /BIC/FZHW_CUBE1-KEY_ZHW_CUBE11.
    /BIC/FZHW_CUBE2-/BIC/ZGEHALT   = /BIC/FZHW_CUBE1-/BIC/ZGEHALT.
    INSERT /BIC/FZHW_CUBE2.
  ENDSELECT.
the problem is the insert statement. if the interpreter reaches this step in the code, we get a dump with the following message:
" Database error text........: "ORA-14400: inserted partition key does not map to   
  any partition"                                                                   
now i assume - since this cube can be loaded with data normally - that it is not possible to store data in an info cube directly using a simple insert statement. are there any appropriate function modules to condense data in a request and load it into an info cube?
Kind Regards.
Gideon.
Message was edited by: Gideon Lenz

Answer 1

hi,
we had a similar error and solved with oss note 339896,
though 2.0b mentioned, it's applicable for our 3.0, please take a look beside the note Vinod mentioned ....(there also mentioned 509660 if f-fact table)
339896
Symptom
During the parallel upload into InfoCubes, ORACLE error ORA14400 might occur in BW 2.0B.
BW2.0B and BW2.1C both originate from the same BW technology basis. Thus 2.0B is a synonym for both releases.
Other terms
Partitioning, ODS, PSA, parallel loading, ORA14400
Reason and Prerequisites
The error can either occur during the insert into the "PSA table" ( /BIC/B00....) or during the insert into the "F-fact table" ( "/BI*/F<INFOCUBE>" ).
If the error occurs when writing to the F-fact table, please refer to Note 509660.
If the error occurs when writing to partitioned PSA tables, an inconsistency exists between administration table "RSTSODS" and the partitions in the database.
Solution
1.) As of Patch 22, CHECK Transaction "RSRV" allows to check the consistency of PSA tables and repair them, if required. (If no name is specified, the CHECK is carried out for all PSA tables.)
2.) Patch < 22: Please check whether function module "RSDDCVER_PSA_PARTITION" exists in your system.
- If yes: Start it for the corresponding PSA table using i_repair = 'X'. Then, the inconsistencies should be eliminated.
- If not: The inconsistencies have to be repaired manually!
Among all partitions of the PSA table, determine the partition with the highest "HIGH VALUE". Compare this partition to the entry in the Partno field of the "RSTSODS" table.
==> Transaction SE16 ---> 'RSTSODS' ---> filter on ODSNAME_TECH with the PSA table name. Error ORA14400 occurs if the entry in the RSTSODS table is higher than the highest partition. To solve the problem, release table RSTSODS in the SAP-DD so that you can change it via Transaction SE16. Then change the entry in the PARTNO field to the value of the highest 'HIGH VALUES'. If the PSA table is empty, enter value '2' in the PARTNO field of the "RSTSODS" table!!!!! The inconsistency may exist in the SAP buffer only. Table RSTSODS is "buffered completely". Before you change the table manually, do submit the command "/$tab rstsods" in the OK-code which invalidates the table in the buffer. If the problem continues to exist, change the entry and invalidate the buffer again by submitting "/$tab rstsods".
509660
Symptom
BW2.0B and BW2.1C are based on the same BW technology.2.0B is therefore a synonym for both releases.
The ORACLE error ORA14400 can occur in BW 2.0B//2.1C during writing to InfoCubes.
Other terms
Partitioning, parallel loading, F fact table, ORA00054, ORA14400, ORA14074, ORA02149
Reason and Prerequisites
The error can also occur during writing to PSA tables or when ODS objects are activated. Refer to note 339896 in this case.As of 2.0B, the F fact table in an BW/ORACLE environment is "range-partitioned" according to the package dimension.A new partition is created when a request is written to requests in the F fact table.If creation of the partition is not successful, ORACLE error 14400 ( "inserted partition key is beyond highest legally partition key" ). There are several causes for this:
1. During loading, there are jobs running (such as ANALYZE TABLE ... CREATE INDEX... ) which lock the table in the ORACLE catalog and take a very long time.Creating the partition on the database takes a very long time;In this case, the ORA00054 error (resource busy) is issued.
2. during parallel loading, an error occurs because an optimistic blocking concept is implemented in the update.
Adding a partition is linked to writing the package dimension entry. If the loading process terminates in such a way that the dimension entry was written, but the partition was not created, the second loading process terminates with ORACLE error ORA14400.
Solution
As of patch BW 2.0B 15 / BW 2.1C 7, creation of a new partition by a SAP lock is saved.If a lock is already present, the program tries to get the lock 100 more times and then continues.In the case of parallel loading processes, this optimistic lock approach always resulted in the ERROR.For this reason, the parameter _wait is set to True in the "RSTMPLWI" template for BW 2.0B patch 21 / BW 2.1C 13 when the enqueue function is called and the loop counter is set to 500, so that the loaders wait longer before continuing.
First select the test "Unused entries in the dimensions of a InfoCube" for the corresponding CUBE via transaction "rsrv"  ==>  InfocubeData and press "Eliminate error". The entry is then deleted in the dimension and during the next loading process, a new entry is generated and the partition is created.
The correction instructions for BW 2.9B patch 15 - 20 / BW 2.1C patch 7 - 12 is attached.In this way, the programs from the corrected TEMPLATE are regenerated.
If the error persists in spite of this change, check whether the F fact table is analyzing or whether indexes are being generated on the F fact table at the same time as the load process.
The program RSTMPLWI is an ABAP template where the update programs are generated. ==> For this reason, automatic installation is not possible and you can not run a syntax check!