Short dumo assertion_failed

Hello Experts,
Am creating transformation on update rules, then i got a short dump:
The ASSERT condition was violated
"ASSERTION_FAILED" " "
"CL_RSTRAN_TEMPLATE============CP" or "CL_RSTRAN_TEMPLATE============CM003"
"CREATE_CONST"
We are on SAP NetWeaver BI 7.0 with SAPKW70014.
Can anybody help me?
Regards,
Yunus

Thanks Sam for ur reply,
I've got doubt. in the selection criteria ive given
GROUPID = 'space'
GROUPTYPE = 'S'
REF_RULE = 'space'
i got all the records with grouptype = s, shall i delete all the records with grouptype = s.
i didnt find any groupid = 00,
is it like all the conditions should fullfill or any one.
Im confused, plz help me.
Thanks.

Similar Messages

Short Dump 'ASSERTION_FAILED' during updating partner Functions

Hi All,
I am updating the Partner Functions for the Customers using FM 'SD_CUSTOMER_MAINTAIN_ALL' and passing the partner functions and numbers to the XKNVP structure.
while running the program in am getting the short dump as ASSERTION_FAILED.
Detailed Description:
In the running application program, the ASSERT statement recognized a situation that should not have occurred.
The runtime error was triggered for one of these reasons:
- For the checkpoint group specified with the ASSERT statement, the activation mode is set to "abort".
- Via a system variant, the activation mode is globally set to "abort" for checkpoint groups in this system.
- The activation mode is set to "abort" on program level.
- The ASSERT statement is not assigned to any checkpoint group.
The Dump is occuring in the method 'get_cvic_cust_to_bp1_line'.
We have searched for a relevant SAP note but could not find any.
can any one please help to solve this issue?
Helpful answer will surely be rewarded.
Thanks in Advance,
Asif Ali Khan

When you are (absolutely) sure you are using this function module in the correct way, only then opening a message for SAP is liable. However, most of the times this happens because not all (or all) parameters are not provided for the FM to work properly, or what ever reason that may be.
It might be helpful to determine the checkpoint group and have a look at the log in transaction SAAB. This might give you a clue as to where the problems lies.

Regarding short dump ASSERTION_FAILED

Hi
I tried to delete info object characteristcs from Info object from transaction RSA1. it gives short dump.
pls advice how to avoid this.
"ASSERTION_FAILED" " "
"CL_RSAWBN_OBJ_IOBC_IOBJTREE===CP" or "CL_RSAWBN_OBJ_IOBC_IOBJTREE===CM002"
"GET_IOBC"
Termination occurred in the ABAP program "CL_RSAWBN_OBJ_IOBC_IOBJTREE===CP" -
in "GET_IOBC".
The main program was "RSAWBN_START ".
In the source code you have the termination point in line 34
of the (Include) program "CL_RSAWBN_OBJ_IOBC_IOBJTREE===CM002".
is it patch problem ?
Regards
Chandra

HI,
Did you saw this?
http://wiki.sdn.sap.com/wiki/display/BI/RuntimeErrorASSERTION_FAILEDinABAPProgramCL_RSAWBN_TREE_VIEW
Regards
Lucas

RSA1 - Datasources ASSERTION_FAILED short dump

Hello,
We are getting a short dump (ASSERTION_FAILED) when clicking on Datasources tab in RSA1 -> Modeling. This was working fine till yesterday afternoon. The last action I performed was to activate all transfer structures in My self source system using RS_TRANSU_ACTIVATE_ALL. I searched on service marketplace but couldn't find any note relevant to our error.
Everything else works fine. Please advise.
We are on BI SP14.
This is the log from st22.
Short text
    The ASSERT condition was violated.
What happened?
    In the running application program, the ASSERT statement recognized a
    situation that should not have occurred.
    The runtime error was triggered for one of these reasons:
    - For the checkpoint group specified with the ASSERT statement, the
      activation mode is set to "abort".
    - Via a system variant, the activation mode is globally set to "abort
      for checkpoint groups in this system.
    - The activation mode is set to "abort" on program level.
    - The ASSERT statement is not assigned to any checkpoint group.
Error analysis
    The following checkpoint group was used: "No checkpoint group specified"
    If in the ASSERT statement the addition FIELDS was used, you can find
    the content of the first 8 specified fields in the following overview:
    " (not used) "
    " (not used) "
    " (not used) "
    " (not used) "
    " (not used) "
    " (not used) "
    " (not used) "
    " (not used) "
How to correct the error
    Probably the only way to eliminate the error is to correct the program.
    If the error occures in a non-modified SAP program, you may be able to
    find an interim solution in an SAP Note.
    If you have access to SAP Notes, carry out a search with the following
    keywords:
    "ASSERTION_FAILED" " "
    "CL_RSAWBN_TREE_VIEW===========CP" or "CL_RSAWBN_TREE_VIEW===========CM00K"
    "EXPAND_NODE"
Best Regards
RT
null

Hello Voodi,
998730 talks about the short dump when changing/activating transformations.
We got the short dump when trying to get into Datasources tab. Though we are on BI, as i mentioned earlier the last action i performed was to activate transfer structures (For 3.x statistical datasources).
Still, I checked the table contents as mentioned in the note. It was not of much help. Any other thoughts?
Thanks.
Message was edited by:
        SAPBI IP

ASSERTION_FAILED runtime error

Hi,
We are working on BI7.0 and updated the patches just yesterday to Support Package 17.
Today i tried to upload the data we got the short dump ASSERTION_FAILED error.
I checked on SDN , there were suggestion to apply note 998730.
in that we have to delete the data in a table RSTRANRULE with entries *.
what this * means does it mean any value.........?
please suggest.......its really urgent.
Regards
Archana W.

Hello,
Have you done any full and then Init/delta?
What are the loading you have performed before and after SP upgrade?
If you can identify that some request would have caused, you can perform a selective deletion.
if the volume is less better you can go for a new Init / delta.
Thanks
Chandran

ASSERTION_FAILED in WDA

Hello,
I have developed a WDAbap (Welcome) program for Portal which is very simple. In this program all I have is Mayo logo picture and text in text field "Welcome to portal".
Then I ran this from EPD and EPQ with no problem. However when we moved it to EPP we are getting short dump "ASSERTION_FAILED". Following is the message we get.
What happened?
In the running application program, the ASSERT statement recognized a
situation that should not have occurred.
The runtime error was triggered for one of these reasons:
- For the checkpoint group specified with the ASSERT statement, the
activation mode is set to "abort".
- Via a system variant, the activation mode is globally set to "abort"
for checkpoint groups in this system.
- The activation mode is set to "abort" on program level.
- The ASSERT statement is not assigned to any checkpoint group.
Since it doesn't happen in CRD and CRQ I believe it's could be a system varian as the message says.
Any help is highly appreciated.
Thanks.
Bijay

Looks like there is statement called "ASSERT", in your code
ASSERT logical_expr.
When an ASSERT statement is executed, the logical expression logical_expr is evaluated. If the expression is true, processing continues with next statment. If the expression is false, program execution is aborted by issubg the runtime error ASSERTION_FAILED.
If you want to check some condition use IF & remove this ASSERT statement.
*Reward each useful answer
Raja T

RSA1 Dump

Hi,
I Have an abap short dump     ASSERTION_FAILED    CL_RSAWBN_TREE_VIEW===========CP when I call transaction rsa1.
the short dump showed after executing program UJS_activate_content. ( to install ENVIRONMENTSHELL)
My configuration is : SAP BW 740 SP02 ON HANA.
                              BI CONTENT 747 SP07
                              CPMBPC 801 SP05
                              HANABPC SP00
Can any one help me it is very critical?
Best Regards,
RAFIK,

    Hi,
I reposted it but I think it is also an SAP BW on hana Problem.
RAFIK,

Transport error (Return code 12)

Hi All,
I recently migrated dataflows from 3.5 to 7.
When I try to transport a transformation (between a DSO to cube) and its DTP, I am getting a transport error (short dump) ASSERTION_FAILED with Return code 12. Has anyone faced this problem before? Any suggestions are appreciated.
I have transported so many migrated dataflows before but never faced this problem before. There is nothing really special about this transformation and DTP. So I am unable to understand what the problem might be.
Thanks,
Sirish.

Hi,
Check the dump in ST22 for detail message. Also, check the following notes:
1114409
1125231
1152985
1155036 : Transformation: Important corrections for BI SP 17-18
1136924 BI7.0(SP18) Dump during content creation for conver
1125231 BI7.0(SP17) Dump when you activate transformations
1122482 BI7.0(SP17) Problems occur when you maintain units
1094978 Transformation: Important corrections for BI7.0 SP1
1090060 BI7.0(SP16) Enhanced transformation check
1011475 Syntax error in CL_RSTRAN_TRFN_RULE after you import SP10
Thanks..
Shambhu

ASSERTION_FAILED short dump when Transporting Transformation from Dev to QA

Hi Experts,
I' am getting a short Dump when transporting the transformations, DSO & DTPs from Dev server to QA.
I got RC=12, Please have a look below....
Transport log...
    BCQ        System BCQ
               Selection for Import                     08.07.2010 15:28:59    (0) Successfully Completed
               Import                                   08.07.2010 15:35:14    (0) Successfully Completed
               Check Versions                           08.07.2010 15:35:14    (0) Successfully Completed
               Method Execution                         08.07.2010 15:36:20   (12) Canceled
               Import                                   08.07.2010 15:45:39    (0) Successfully Completed
               Check Versions                           08.07.2010 15:45:39    (0) Successfully Completed
               Method Execution                         08.07.2010 15:46:45   (12) Canceled
and the Log detalis.....
Date        Time      Message
08.07.2010 15:35:15 Job started
08.07.2010 15:35:15 Step 001 started (program RDDEXECL, variant , user ID DDIC)
08.07.2010 15:35:15 All DB buffers of application server sxcat136 were synchronized
08.07.2010 15:35:21 STDO: Log could not be written on output device T
08.07.2010 15:35:30 Replication completed successfully
08.07.2010 15:35:31 Struttura di comunicazione /BIC/CS8ZFIZIASA activated
08.07.2010 15:35:40 Regola(e) di trasm. 8ZFIZIASA_AA activated
08.07.2010 15:35:47 ABAP/4 processor: ASSERTION_FAILED
08.07.2010 15:35:47 Job cancelled
Even I've checked the entries on the table RSTRANRULE for those Transpormations but there I got...all the entries with...
RULEID = all numbers
GROUPID = '1' or '2'
GROUPTYPE = 'S' or 'T'
REF_RULE ='0'
we are in to SAP_BW Release 700, Level 0013, SP -SAPKW70013, SAP NetWeaver BI 7.0
Pls help if any one know's the solution for this.
Thanks in adv.
BR,
Ajay Kumar
Edited by: sap.ajaykumar on Jul 9, 2010 12:48 PM

Follow the steps mentioned in OSS note 998730.
FYI.. Solution:
Call transaction SE16 (Table Browser) and the 'RSTRANRULE' table with the following selection parameters:
GROUPID = 'space'
GROUPTYPE = 'space'
REF_RULE 'space'
If there are inconsistent entries in the RSTRANRULE table such as this:
TRANID *
OBJVERS *
RULEID *
SEQNR *
GROUPID 00
GROUPTYPE space
RULETYPE space
REF RULE *
Delete these entries from the table.
Activate the affected transformations.
Also check the OSS note: 1006658.
Follow the steps mentioned in OSS note 998730.
FYI.. Solution:
Call transaction SE16 (Table Browser) and the 'RSTRANRULE' table with the following selection parameters:
GROUPID = 'space'
GROUPTYPE = 'space'
REF_RULE 'space'
If there are inconsistent entries in the RSTRANRULE table such as this:
TRANID *
OBJVERS *
RULEID *
SEQNR *
GROUPID 00
GROUPTYPE space
RULETYPE space
REF RULE *
Delete these entries from the table.
Activate the affected transformations.
Also check the OSS note: 1006658.
Follow the steps mentioned in OSS note 998730.
FYI.. Solution:
Call transaction SE16 (Table Browser) and the 'RSTRANRULE' table with the following selection parameters:
GROUPID = 'space'
GROUPTYPE = 'space'
REF_RULE 'space'
If there are inconsistent entries in the RSTRANRULE table such as this:
TRANID *
OBJVERS *
RULEID *
SEQNR *
GROUPID 00
GROUPTYPE space
RULETYPE space
REF RULE *
Delete these entries from the table.
Activate the affected transformations.
Also check the OSS note: 1006658.
Also check the oSS note : Note 975675 - Transformation cannot be activated

ASSERTION_FAILED, Short dump when activating Transformation in BI7.0

Hi All,
I have migrated 3.5 update rule to 7.0. And during transformation activation i am getting short dump giving following messges:
"ASSERTION_FAILED"
"CL_RSTRAN_GEN_STEP= = = = = CP"
"CL_RSTRAN_GEN_STEP= = = = = CM005"
"GET_CONTAINER"
My system support pack is 15. I searched many OSS Notes but i am not able to get the exact soln.
can anybody help me out with this problem?
Regards,
Harsh

this error is generally due to inconsistency in metadata
refer OSS note: 1071255, 1094266, 998730, 829353, 926854
Try to implement this solution from OSS 998730:
Call transaction SE16 (Table Browser) and the 'RSTRANRULE' table with the following selection parameters:
GROUPID = 'space'
GROUPTYPE = 'space' or 'S'
REF_RULE <> 'space'
If there are inconsistent entries in the RSTRANRULE table such as:
 TRANID *
OBJVERS *
RULEID *
SEQNR *
GROUPID 00
GROUPTYPE space or GROUPTYPE 'S'
RULETYPE space
REF RULE *
Delete these entries from the table.
Activate the affected transformations.
Edited by: sam hennry on Feb 5, 2008 4:40 PM

Short dump when expand info provide

Dear all,
I have 0GL_ACOOUNT info object that act as a master data.
the problem is when I want to expand at the info provider instantly create short dump
the overview of the short dump is :
Runtime Errors ASSERTION_FAILED
Date and Time 12.08.2009 10:08:16
Short text
 The ASSERT condition was violated.
What happened?
 In the running application program, the ASSERT statement recognized a
 situation that should not have occurred.
 The runtime error was triggered for one of these reasons:
 - For the checkpoint group specified with the ASSERT statement, the
 activation mode is set to "abort".
 - Via a system variant, the activation mode is globally set to "abort"
 for checkpoint groups in this system.
 - The activation mode is set to "abort" on program level.
 - The ASSERT statement is not assigned to any checkpoint group.
What can you do?
 Note down which actions and inputs caused the error.
 To process the problem further, contact you SAP system
 administrator.
 Using Transaction ST22 for ABAP Dump Analysis, you can look
 at and manage termination messages, and you can also
 keep them for a long time.
Information on where terminated
 Termination occurred in the ABAP program "CL_RSAWBN_OBJ_IOBJ_DATA=======CP" -
 in "GET_TRFN_AWBSUBOBJ".
 The main program was "RSAWBN_START ".
 In the source code you have the termination point in line 23
 of the (Include) program "CL_RSAWBN_OBJ_IOBJ_DATA=======CM005".
Source Code Extract
Line SourceCde
 1 METHOD get_trfn_awbsubobj .
 2
 3 DATA: l_tranid TYPE rstranid,
 4 l_s_source TYPE rstran_s_tlogo,
 5 l_s_target TYPE rstran_s_tlogo,
 6 l_objvers TYPE rsobjvers.
 7
 8 l_tranid = i_objnm.
 9 l_objvers = rs_c_objvers.
 10
 11 * get the source and target for the tranid
 12 WHILE l_s_source IS INITIAL OR l_s_target I
 13 TRY.
 14 cl_rstran_stat=>get_objects(
 15 EXPORTING
 16 i_tranid = l_tranid
 17 i_objvers = l_objvers
 18 IMPORTING
 19 e_s_source = l_s_source
 20 e_s_target = l_s_target
 21 ).
 22 CATCH cx_rstran_not_found .
>>>>> ASSERT sy-index < 2.
 24 ENDTRY.
 25 * for possible second run set objvers
 26 l_objvers = rs_c_objvers-modified.
 27 ENDWHILE.
29 * pass back the su
30 IF i_target = rs
31 re_awbsubobjec
32 ELSE.
33 re_awbsubobjec
34 ENDIF.
35
36 ENDMETHOD.
Please advice

HI,
I have read the sap notes and that is exactly what happen to me.
but I don't understand how to correct it.
It said :
This error cannot be corrected automatically. Use the method DELETE_VERSION_FROM_DB of the class CL_RSTRAN_STAT to delete the existing A version of the transformation manually in the target system.
Ensure that the transformation is permanently deleted from the database; therefore, you should verify that the correct transformation ID is specified (in the short dump, the TranID that is specified in the short dump is in the variable L_TRANID).
anybody know how to use delete_version_from_db ?
please advice

ASSERTION_FAILED with program RGIMOVV0 during XPRA PHASE ; LEDGER SCENARIOS

Hello guys, i'm having a problem applying support package EHP3 into an ECC system . some short part of the dump text : Runtime Errors ASSERTION_FAILED Date and Time 17.09.2009 15:05:51 -
|Short text | | The ASSERT condition was violated. | -
|How to correct the error | | Probably the only way to eliminate the error is to correct the program. | | - | | | | If the error occures in a non-modified SAP program, you may be able to | | find an interim solution in an SAP Note. | | If you have access to SAP Notes, carry out a search with the following | | keywords: | | | | "ASSERTION_FAILED" " " | | "RGIMOVV0" or "RGIMOVV0" | | "FILL_LEDGER_SCENARIOS" | -
|Information on where terminated | | Termination occurred in the ABAP program "RGIMOVV0" - in | | "FILL_LEDGER_SCENARIOS". | | The main program was "RGZZGLUX ". | | | | In the source code you have the termination point in line 1724 | | of the (Include) program "RGIMOVV0". | | The program "RGIMOVV0" was started as a background job. | | Job Name....... "RDDEXECL" | | Job Initiator.. "DDIC" | | Job Number..... 15054200 | -
|Source Code Extract | -
|Line |SourceCde | -
| 1694| | | 1695|ENDFORM. " create_add_mov_for_gl_ledger | | 1696| | | 1697|&---- | | 1698|& Form fill_ledger_scenarios | | 1699|&--* | | 1700|* text | | 1701|*--
* | | 1702|FORM fill_ledger_scenarios USING iv_fieldmovement TYPE feldmodif | | 1703| iv_interface TYPE gl_interface | | 1704| is_t881 TYPE t881 | | 1705| it_ledger_scen TYPE ty_ledger_scen_tab | | 1706| it_scen_fields TYPE ty_scen_fields_tab | | 1707| it_cust_fields TYPE ty_cust_fields_tab. | | 1708| | | 1709| DATA: ls_ledger_scen TYPE fagl_ledger_scen, | | 1710| ls_scen_field TYPE fagl_scen_fields, | | 1711| ls_field_move TYPE fagl_field_move, | | 1712| ls_field_movec TYPE fagl_field_movec, | | 1713| ls_cust_field TYPE fagl_cust_fields, | | 1714| lv_lfieldname TYPE dfies-lfieldname. | | 1715| | | 1716| LOOP AT it_ledger_scen INTO ls_ledger_scen. | | 1717| LOOP AT it_scen_fields INTO ls_scen_field | | 1718| WHERE scenario = ls_ledger_scen-scenario | | 1719| AND interface = iv_interface. | | 1720| READ TABLE gt_field_move INTO ls_field_move | | 1721| WITH TABLE KEY totable = is_t881-tab | | 1722| tofield = ls_scen_field-field | | 1723| interface = iv_interface. | |>>>>>| ASSERT sy-subrc = 0. | | 1725|* co-pa interface table is generated, so first check if field really exists | | 1726| IF iv_interface = gc_copa_interface. | | 1727| MOVE ls_field_move-fromfield TO lv_lfieldname. | | 1728| CALL FUNCTION 'DDIF_NAMETAB_GET' | | 1729| EXPORTING | | 1730| tabname = ls_field_move-fromtable | | 1731| lfieldname = lv_lfieldname | | 1732| EXCEPTIONS | | 1733| OTHERS = 1. | | 1734| CHECK sy-subrc = 0. | | 1735| ENDIF. | | 1736| PERFORM append_field USING ls_ledger_scen-client iv_fieldmovement ls_scen_field-field | | 1737| ls_field_move-fromtable ls_field_move-fromfield ls_field_move-exitname. | | 1738| ENDLOOP. | | 1739| ENDLOOP. | | 1740| | | 1741| LOOP AT it_cust_fields INTO ls_cust_field. | | 1742| READ TABLE gt_field_movec INTO ls_field_movec | | 1743| WITH TABLE KEY totable = is_t881-tab | -
did someone of you experience a problem of this kind?
Even performing a local copy I experienced the same and running the program RGIMOVV0 from se38 leads to the same dump. Our development is in stuck .
Regards to all

we have deleted three entries from a table cuasing the dump. ALL the entries with to field PROJK .
Do not know but somone maybe started a project in the ledger scenario that put those entries in the table.
If you go in spro at the voice" assign ledger scenario" it should lead you to the same dump.
try !

ASSERTION_FAILED with program RGIMOVV0 during XPRA PHASE

Hello guys,
i'm having a problem applying support package EHP3 into an ECC system .
some short part of the dump text :
Runtime Errors         ASSERTION_FAILED
Date and Time          17.09.2009 15:05:51
Short text
The ASSERT condition was violated.
How to correct the error
Probably the only way to eliminate the error is to correct the program.
If the error occures in a non-modified SAP program, you may be able to
find an interim solution in an SAP Note.
If you have access to SAP Notes, carry out a search with the following
keywords:
"ASSERTION_FAILED" " "
"RGIMOVV0" or "RGIMOVV0"
"FILL_LEDGER_SCENARIOS"
Information on where terminated
Termination occurred in the ABAP program "RGIMOVV0" - in
"FILL_LEDGER_SCENARIOS".
The main program was "RGZZGLUX ".
In the source code you have the termination point in line 1724
of the (Include) program "RGIMOVV0".
The program "RGIMOVV0" was started as a background job.
Job Name....... "RDDEXECL"
Job Initiator.. "DDIC"
Job Number..... 15054200
Source Code Extract
Line
SourceCde
1694
1695
ENDFORM.                    " create_add_mov_for_gl_ledger
1696
1697
1698
*&      Form fill_ledger_scenarios
1699
1700
      text
1701
1702
FORM fill_ledger_scenarios USING iv_fieldmovement TYPE feldmodif
1703
iv_interface TYPE gl_interface
1704
is_t881 TYPE t881
1705
it_ledger_scen TYPE ty_ledger_scen_tab
1706
it_scen_fields TYPE ty_scen_fields_tab
1707
it_cust_fields TYPE ty_cust_fields_tab.
1708
1709
DATA: ls_ledger_scen TYPE fagl_ledger_scen,
1710
ls_scen_field TYPE fagl_scen_fields,
1711
ls_field_move TYPE fagl_field_move,
1712
ls_field_movec TYPE fagl_field_movec,
1713
ls_cust_field TYPE fagl_cust_fields,
1714
lv_lfieldname TYPE dfies-lfieldname.
1715
1716
LOOP AT it_ledger_scen INTO ls_ledger_scen.
1717
LOOP AT it_scen_fields INTO ls_scen_field
1718
WHERE scenario = ls_ledger_scen-scenario
1719
AND interface = iv_interface.
1720
READ TABLE gt_field_move INTO ls_field_move
1721
WITH TABLE KEY totable = is_t881-tab
1722
tofield = ls_scen_field-field
1723
interface = iv_interface.
>>>>>
ASSERT sy-subrc = 0.
1725
    co-pa interface table is generated, so first check if field really exists
1726
IF iv_interface = gc_copa_interface.
1727
MOVE ls_field_move-fromfield TO lv_lfieldname.
1728
CALL FUNCTION 'DDIF_NAMETAB_GET'
1729
EXPORTING
1730
tabname    = ls_field_move-fromtable
1731
lfieldname = lv_lfieldname
1732
EXCEPTIONS
1733
OTHERS     = 1.
1734
CHECK sy-subrc = 0.
1735
ENDIF.
1736
PERFORM append_field USING ls_ledger_scen-client iv_fieldmovement ls_scen_field-field
1737
ls_field_move-fromtable ls_field_move-fromfield ls_field_move-exitname.
1738
ENDLOOP.
1739
ENDLOOP.
1740
1741
LOOP AT it_cust_fields INTO ls_cust_field.
1742
READ TABLE gt_field_movec INTO ls_field_movec
1743
WITH TABLE KEY totable = is_t881-tab
did someone of you experience a problem of this kind?
Even performing a local copy I experienced the same and running the program RGIMOVV0 from se38 leads to the same dump. Our development is in stuck .
Regards to all

Dear sirs -
Were you able to solve your problem? We are trying to execute a client copy and cannot finish post processing steps.
We have a note into SAP as well.
Brenda

ASSERTION_FAILED when Activate a DTP

I got an error message when trying to activate a DTP. Does anyone know how to fix it? Thanks!
Runtime Errors ASSERTION_FAILED
Date and Time 03/27/2007 14:29:57
Short dump has not been completely stored (too big)
Short text
 The ASSERT condition was violated.
What happened?
 In the running application program, the ASSERT statement recognized a
 situation that should not have occurred.
 The runtime error was triggered for one of these reasons:
 - For the checkpoint group specified with the ASSERT statement, the
 activation mode is set to "abort".
 - Via a system variant, the activation mode is globally set to "abort"
 for checkpoint groups in this system.
 - The activation mode is set to "abort" on program level.
 - The ASSERT statement is not assigned to any checkpoint group.
Error analysis
 The following checkpoint group was used: "No checkpoint group specified"
 If in the ASSERT statement the addition FIELDS was used, you can find
 the content of the first 8 specified fields in the following overview:
 " (not used) "
 " (not used) "
 " (not used) "
 " (not used) "
 " (not used) "
 " (not used) "
 " (not used) "
 " (not used) "
Trigger Location of Runtime Error
 Program CL_RSAR_PSA===================CP
 Include CL_RSAR_PSA===================CM006
 Row 152
 Module type (METHOD)
 Module Name UPDATEDIRECTORY_TABLES
Source Code Extract
Line SourceCde
122 i_uni_idc25 = l_codeid
123 i_program_class = 'RSAR_ODS_MAINTAIN'
124 EXCEPTIONS
125 deletion_rejected = 2
126 OTHERS = 3.
127 ENDIF.
128 ENDIF.
129 UPDATE rstsods SET tstpnm = sy-uname
130 timestmp = l_s_ods-timestmp
131 userapp = p_userapp
132 userobj = p_userobj
133 maintprog = ''
134 WHERE odsname = l_s_odsfield-odsname
135 AND version = l_s_odsfield-version.
136 IF sy-subrc = 0.
137 IF i_partitioned = rs_c_true.
138 *-- Entry could exist but includes no partition number,
139 * because the PSA was not partitioned before
140 l_tablnm = p_psa_techname.
141
142 CALL FUNCTION 'RSDU_PARTITIONS_INFO_GET'
143 EXPORTING
144 i_tablnm = l_tablnm
145 IMPORTING
146 e_ts_part_info = l_ts_part_info
147 EXCEPTIONS
148 table_not_exists = 1
149 table_not_partitioned = 2
150 OTHERS = 3.
151
>>> ASSERT sy-subrc = 0.
153
154 DESCRIBE TABLE l_ts_part_info LINES l_num_partitions.
155 READ TABLE l_ts_part_info INDEX l_num_partitions INTO l_s_part_info.
156 l_highest_partvalue = l_s_part_info-high_value.
157
158 UPDATE rstsods SET partno = l_highest_partvalue
159 WHERE odsname = l_s_odsfield-odsname
160 AND version = l_s_odsfield-version.
161
162 ENDIF.
163 ELSE.
164 * create new version
165 l_s_ods-odsname = l_s_odsfield-odsname.
166 l_s_ods-version = i_next_version.
167 l_s_ods-dateto = rsods_c_dateto_01019999.
168 l_s_ods-datefrom = rsods_c_datefrom_01011998.
169 l_s_ods-objstat = rs_c_objstat-active.
170 l_s_ods-odsname_tech = p_psa_techname.
171 l_s_ods-progname = i_progname.

I guess it is Notes 1012607.
Summary
Symptom
Note: This note is relevant only for 'ORACLE' and 'MSSQL' database systems. After you implement this note, you must also carry out some manual corrections (see 'Solution', below).
If you are working with database system DB2 or MSSQL, also implement Note 1022026.
When data is written or activated or when a DataStore object is activated, the following errors occur:
Similar errors may also occur for the DataSource and data transfer process (DTP).
ORA-01502: index 'SAPDAT./BIC/A*KE' or partition of such index is in unusable state
Column 'PARTNO' is partitioning column of the index '/BIC/A*KE'. Partition columns for a unique index must be a subset of the index key.
error #RSDU_TABLE_TRUNC_PARTITION_MSS: Error While Calling Module MSS_TRUNC_PARTITION_FROM_TABLE Message no. 0U534#.
ASSERTION_FAILED in class 'CL_RSAR_PSA'.
Error message D0 313 in the activation log. The message does not contain any text. In the activation log it is displayed as an empty line with a red traffic light.
Other terms
DBIF_RSQL_SQL_ERROR, D0 313, D0313
Reason and Prerequisites
Reason:
The partitioning logic of the persistent staging area (PSA) service does not recognize that the PARTNO field must not be deleted.
For write-optimized DataStore objects, the active table is created as a partitioned table, even though a global index is used to ensure uniqueness of data. This is not compatible with the 'drop of a partition'.
In the DataSource maintenance, you have the option to define key fields. For the first 16 key fields of the DataSource field list, a global index is also created.
If 'semantic groups' are used in the DTP, the error stack is created with a global index.
Solution
Implement the corrections by importing the Support Package or by implementing the advance correction. As a result, the 'range' partitioning is deactivated in the PSA service as soon as a global index is requested.
The error can occur for the objects: DataStore (only the write-optimized type), DataSource, and error stack of the DTP.
This note contains the 'RSAR_PSA_PARTITION_CHECK' program, which you can use to analyze the objects. Execute the program. Use the search strings listed in section 5), depending on whether you want to analyze individual objects or object types. If you do not make an entry in the PODSTECH field (technical name of the PSA), the system checks all existing PSA tables, which may take some time.
You can use transaction SLG1 to display the log for 'RSAR_PSA_PARTITION_CHECK'. Select the following:
 Object = 'RSAR'
Subobject = 'METADATA'
Ext. Identif. = 'RSAR_PSA_PARTITION_CHECK'
You must make different manual changes to repair each of the different object classes.
1) DataStore (write-optimized)
Incorrect DataStores are identified in the log of the check program with the PSA type 'FASTSTORE'. The name after 'Obj:' is the technical name of the corresponding DataStore object.
For a DataStore object of the 'write-optimized' type, a global index with relation to the semantic key is created if the 'Do Not Check Uniqueness of Data' indicator is not set.
Check if you need to ensure that data is unique in your scenario.
1. If you do not need the data to be unique:
 Set the flag: 'Do Not Check Uniqueness of Data', and activate the DataStore object. The DataStore object is now consistent again.
2. If you need unique data:
In this case, you must departition and convert the table.
If the error occurred when you activate the DataStore itself or when you activate the data, you must activate the DataStore object after converting the active table. You need the technical name of the active table for the conversion. You can get this directly from the log of 'RSAR_PSA_PARTITION_CHECK'. If you know which DataStore contains errors, find the technical name of the active table in the Maintain DataStore screen by choosing:
 <Extras> ->
 'Information (logs/status)
Choose 'Dictionary DB status' to access the status POPUP. You can find the technical name in the 'Active table' field.
If the table does not contain any data according to the 'RSAR_PSA_PARTITION_CHECK' log, the table is automatically departitioned when you activate the DataStore.
If the table contains data, you must departition and convert the table as described in section 4.
After that, use the AdminWorkBench (transaction RSA1) to activate the DataStore object.
2) DataSource:
Incorrect DataSources are identified in the log of the check program with the PSA type 'NEW_DS'. The 'Obj:' indicator is followed by two additional character strings. The first is the technical name of the relevant DataSource. The second is the technical name of the source system.
PSA tables for DataSources with a key definition must be departitioned.
The name of the PSA table for the DataSource is contained directly in the 'RSAR_PSA_PARTITION_CHECK' log.
If the table does not contain any data according to the 'RSAR_PSA_PARTITION_CHECK' log, the table is automatically departitioned when you activate the DataStore.
If the table contains data, you must departition and convert the table as described in section 4.
Call transaction 'RSDS' and enter the technical name of the DataSource and the source system and activate the DataSource.
3) Error stacks for the DTP:
Incorrect Error Stacks are identified in the log of the check program with the PSA type 'ERRORSTACK'. The 'Obj:' indicator is followed by the technical name of the relevant DTP. There may be more than one error stack table for each DTP.
PSA tables for ErrorStack with a key definition must be departitioned.
The name(s) of the PSA Error Stack table(s) for the DTP is/are contained directly in the 'RSAR_PSA_PARTITION_CHECK' log.
If the table does not contain any data according to the 'RSAR_PSA_PARTITION_CHECK' log, the table is automatically departitioned when you activate the DTP.
If the table contains data, you must departition and convert the table as described in section 4.
Now call transaction RSDTP, enter the technical name of the DTP and activate the DTP.
4) Departitioning and converting
The following manual conversion using transaction SE14 is supported only for ORACLE database systems. Open a problem message under component BW-SYS-DB-MSS if you need to convert tables on a MSSQL database system.
Call transaction SE14 (Database Utility) for the tables you need to convert. Select 'Table', enter the technical name of the table and choose 'Edit'.
On the next screen, choose 'Storage Parameters' (Shift+F6).
On the next screen (Storage Parameters), choose 'For new creation' (F8).
In the dialog box that then appears, select 'Current database parameters' and copy it by choosing 'Enter'.
You now get an overview of the storage parameters <Tables>, <Indexes> and existing <Partitions>.
Under the 'Table' node, if the content of the 'TABLESPACE' field is initial, enter the value from the 'TABLESPACE' field of the first partition.
For the field 'PARTITIONED BY', choose the option 'No partitioning' and save your changes.
Exit the screen with the storage parameters.
On the next screen, ensure that the 'Save data' radio button after 'Activate and adjust database' is selected, then execute the conversion. You execute the conversion by choosing 'Force Conversion' in the <Extras> menu.
Next, you must correct the PARTNO indicator in table RSTSODS. To do this, call transaction RSRV and execute the test 'Consistency Between PSA Partitions and SAP Administration Information'. You can find this test in transaction RSRV under
<All Elementary Tests>
 -> <PSA Tables>
You can execute the RSRV test and repair for all converted tables at once. For further information about how to use transaction RSRV in this case, see the online documentation. You can call the online documentation by choosing the 'Info' icon.
5) Search strings:
a) Use the search string '/BI+/B*' to find the relevant entries for the DataSource, the change logs and the error stack.
b) Use the search string '/BI+/A*00' to find the relevant entries in the active tables for the DataSource objects.
SAP NetWeaver 2004s BI
 Import Support Package 13 for SAP NetWeaver 2004s BI (BI Patch 13 or SAPKW70013) into your BI system. The Support Package is available once Note 991093 "SAPBINews BI 7.0 Support Package 13", which describes this Support Package in more detail, has been released for customers.
In urgent cases, you can implement the correction instructions as an advance correction.
You must first implement Notes 932065, 935140, 948389, 964580, 969846, 975510, 983212 and 1000448, which provide information about transaction SNOTE. Otherwise, problems and syntax errors may occur when you deimplement certain notes.
To provide information in advance, the notes mentioned above may already be available before the Support Package is released. In this case, the short text of the note still contains the words "Preliminary version".
Before you implement an advance correction (if one exists and you want to implement it), see Note 875986. This contains notes regarding the SAP Note Assistant and these notes prevent problems during the implementation.

Getting Error ASSERTION_FAILED while activating transformation.

Hi Experts,
I am getting an error "The ASSERT condition was violated" while activating a transformation in BI. I applied SAP NOTE 1137447 and I am still getting this error given below.
Runtime Errors         ASSERTION_FAILED
Date and Time          09.10.2009 16:53:20
Short text
     The ASSERT condition was violated.
What happened?
     In the running application program, the ASSERT statement recognized a
     situation that should not have occurred.
     The runtime error was triggered for one of these reasons:
     - For the checkpoint group specified with the ASSERT statement, the
       activation mode is set to "abort".
     - Via a system variant, the activation mode is globally set to "abort"
       for checkpoint groups in this system.
     - The activation mode is set to "abort" on program level.
     - The ASSERT statement is not assigned to any checkpoint group.
Error analysis
     The following checkpoint group was used: "No checkpoint group specified"
     If in the ASSERT statement the addition FIELDS was used, you can find
     the content of the first 8 specified fields in the following overview:
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
     " (not used) "
Trigger Location of Runtime Error
    Program                                 CL_RSTRAN_FOBU_APPL===========CP
    Include                                 CL_RSTRAN_FOBU_APPL===========CM007
    Row                                     37
    Module type                             (METHOD)
    Module Name                             GET_CODE
Line SourceCde
    7     l_formula_id_32   TYPE sfbeid,
    8     l_s_fobu          TYPE rsfob_s_formula,
    9     l_r_formula       TYPE REF TO cl_foev_formula.
   10
   11
   12   IF p_r_formula IS BOUND AND
   13    p_mode is not initial.
   14     CALL METHOD cl_rsar_formulas=>reset_formula_foev_object
   15       EXPORTING
   16         i_formex    = p_formex
   17         i_objvers   = p_objvers
   18         i_r_formula = p_r_formula
   19       EXCEPTIONS
   20         no_entry    = 1
   21         invalid     = 2
   22         OTHERS      = 3.
   23     ASSERT sy-subrc = 0. "invalid call
   24
   25   ENDIF.
   26
   27   CALL METHOD cl_rsar_formulas=>get_formula_foev_object
   28     EXPORTING
   29       i_formex    = p_formex
   30       i_objvers   = p_objvers
   31     RECEIVING
   32       r_r_formula = l_r_formula
   33     EXCEPTIONS
   34       no_entry    = 1
   35       invalid     = 2
   36       OTHERS      = 3.
>>>>>   ASSERT sy-subrc = 0. "invalid call
   38
   39
   40   l_r_formula->compile( EXPORTING i_structure_prefix = 'SOURCE_FIELDS'
   41                         IMPORTING e_abap_formula = e_t_abap_source ).
   42
   43 ENDMETHOD.
Kindly help me.
Thanks in advance,
With Kind Regards,
Kannan Jagadeesan

Try applying the following OSS Notes:
[OSS Note 1050275 - ASSERTION_FAILED in CL_RSTRAN_FOBU_APPL->GET_CODE|https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1050275] (relevant to prior to BI 7 SP14)
[OSS Note 1115923 - Check or transfer of empty formulas causes runtime error|https://websmp130.sap-ag.de/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/sapnotes/index2.htm?numm=1115923] (relevant to prior to BI 7 SP17).

Short dumo assertion_failed

Similar Messages

Maybe you are looking for