ASSERTION_FAILED on DropdownbyIdx

Hi Gurus,
I need your help on this.
I encountered this error in Internet Explorer but not in Firefox and Chrome.
What happens is, when I triggered my dropdown by index, the column will have blank item first, then dropdown values.
Sample.
     Blank
     Value1
     Value2
When I click blank, nothing happens.
When I click Value1, Value2 got displayed.
When I click Value2, assertion_failed happens.
The error occurs in /1WDA/C0STANDARD==============CP=>IF_WDR_NW7_EVENT_HANDLER~HANDLE_EVENT.
7145
" Assert numeric value
7146
check IFUR_NW7_COMBOBOX~ITEMCOUNT > 0.
7147
assert value co '0123456789-'. "#EC NOTEXT
7148
lead_selection_index = value.
>>>>>
assert lead_selection_index >= 1 and lead_selection_index <= lines( mv_VALUE_SET ) or
7150       
mv_WD_DESELECTABLE = abap_true and lead_selection_index = -1.
When I debug, at first pass on this code, mv_VALUE_SET has 3 items (blank, value1, value2).
On the next pass, mv_VALUE_SET has 2 items (value1, value2) only. The blank item was removed.
How to fix this error?

Hi Rama,
Yes. So far, only in IE.
It's weird because I only select a dropdown value ONCE and it passed through the program (/1WDA/C0STANDARD==============CP=>IF_WDR_NW7_EVENT_HANDLER~HANDLE_EVENT) TWICE.
The code that populates that dropdown is only in ON_DATA_CHECK because the dropdown's value is dependent on the adjacent column's value.
I put break-point in on_data_check.
It only passed through there once.
There's no other way, that I had repopulated that dropdown.

Similar Messages

  • 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#.
    <b>ASSERTION_FAILED in class 'CL_RSAR_PSA'.</b>
    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).

  • Runtime error assertion_failed

    hello,
    i am getting a runtime error 'assertion_failed' while activating the transformations.
    it says the assert condition was violated. i am attaching the error message here.
    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.
    i need help regarding this.
    thanks in advance.
    muralik

    Hello MuraliK,
    Plz apply note :998730.
    U need to check RSTRANRULE  table with certain combination and delete inconsistent records.
    -- Plz assign points if helpful --
    Regards,
    Mainak

  • BDLS failing with ASSERTION_FAILED dump

    Dear Experts,
    We have replaced the existing quality system DF0 with RC0.These both system are quality systems and RC0 has been refreshed from production.
    So in BW qulaity system we need to replace the DF0 with RC0 as source system. I have created logical system name LSRC0310 for RC0 in BW qulaity system and ran a BDLS to convert DF0 to RC0. But it is giving a dump ASSERTION_FAILED.
    Earlier it failed with error that logical system LSRC0310 name alreday exists.So i deleted the logical system name and ran BDLS but it again failed with same error.I have checked the logs and it just makes an entry in table TBDLS, TBDLST. The logs in BDLSS also says that the conversion went in error with "Error in field of table . Manual correction required."
    Thus the source system DF0 is not replaced in RSA1 also i can still see cubes pointing to DF0.
    I have referred to Modify source system link but it is failing in the BDLS step so cannot proceed ahead.
    Please can you guide and help is solving this issue.
    Regards,
    KUldeep.

    Thanks Walter for your reply.
    This note is already present in the system and still BDLS fails with this message.
    I hope my approach is correct.
    Currently source system is DF0 and we want to convert to RC0. So running a BDLS will convert all the logical source system names for all the transfer structure and DTPs and transformations.Then after BDLS step i can restore the source system in RSA1.
    Please confim if my this is feasible.
    Regards,
    Kuldeep.

  • Error when create a new asset ----ASSERTION_FAILED

    Hi,
    I have installed EHP4 FOR SAP ERP 6.0 / NW7.01 and when create new asset with AS01 and try to save the system show me the next runtime errors:
    ASSERTION_FAILED" " "
    CL_FAA_CFG_DEPRAREA_ERP=======CP" or "CL_FAA_CFG_DEPRAREA_ERP=======CM009"
    SETDATA_DERIVATION"
    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.
    I have implemented the note 325531 but no result.
    Do you have any ideea?
    Regards,
    Ionel

    Hi all,
    I have the same problem. I have executed the report RACORR11 mentioned in OSS note 325531 but no changes I still get the dump when I want to save the asset. In my system the report RACORR122 is not available. In the customizing system the asset creation works fine w/o dump but in the test system I get the dump. I have compared the derived depreciation areas in table T093B in customizing and test system and there are the same entries. All transports have been transported from customizing to test system.
    Does anybody have any ideas whatelse can be done to overcome the dump?
    Thanks, Christopher

  • ASSERTION_FAILED while activation of Transformation !

    Hello ,
    While activation of transformation in Development system BI7.0 , following error appears :
    ===============
    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_RSTRAN_GEN_STEP_INIT_CHECK=CP" or "CL_RSTRAN_GEN_STEP_INIT_CHECK=CM001"
        "CONSTRUCTOR"
        If you cannot solve the problem yourself and want to send an error
        notification to SAP, include the following information:
    Information on where terminated
       Termination occurred in the ABAP program "CL_RSTRAN_GEN_STEP_INIT_CHECK=CP" -
        in "CONSTRUCTOR".
       The main program was "RSAWBN_START ".
       In the source code you have the termination point in line 14
       of the (Include) program "CL_RSTRAN_GEN_STEP_INIT_CHECK=CM001".
    Line  SourceCde
        1 METHOD CONSTRUCTOR.
        2   data: l_r_step_dummy type ref to cl_rstran_step,
        3         ls_class       type cl_rstran_gen_step=>ty_s_c
        4
        5
        6   call method super->constructor
        7     exporting
        8       i_r_step = l_r_step_dummy.
        9
       10   o_internal   = rs_c_true.
       11   o_steptype_  = rstr_steptype-initial_value_check.
       12   read table g_t_class into ls_class
       13     with key steptype   = o_steptype_.
    >>>>>   assert sy-subrc = 0.
       15   o_steptypeid_    = ls_class-steptypeid.
       16
       17 ENDMETHOD.
    What I have done already :
    1-Implemented notes :1494809 ,1502803,0001490927, 1458197( No Success)
    2-Entry in Table : Table RSTRANSTEPTYPE and RSTRAN_STEPTYP_R as specified in Note :1494809
    3-No routines in Transformation .All are direct mapping .
    4-No Constant / Formula / Routine mapped in Transformation .
    5-Even I have deleted transformation and re-created ..again same problem..Going to Dump
    Any one of you have faced such issue !!
    Regards
    Vikas Sharma

    Hello ,
    Problem is solved by my self :
    Problem cause :
    1- There was some characteristic which are reference characteristic of 0Date or 0TIME are available for rules mapping .
    So First Identify which are those characteristic in your transformation and delete the rule .
    2- Also check the table /BI0/STIME and /BI0/Sdate and check if there is some wrong values are in it .. like wrong date or time format ...for example : 20.02.0201 ( Date)
    Do follow below steps :
    Data Browser (transaction SE16) to create the following new entries:
    1. Table RSTRANSTEPTYPE
    STEPTYPE          INITIALVALUE_CHECK
    STEPTYPEID        _IV
    ICONNAME
    CLASSNAME
    DBTABLE
    PROGCLASS        RSTRAN_RULE_TMPL_1
    CLASSNAME GEN     CL_RSTRAN_GEN_STEP_UNIT_CHECK
    SECOND PROCESS
    Transport this entry by selecting the entry to be entered INITIALVALUE_CHECK from the list, and writing this to an order using the function "Transport Entries".
    2. Table RSTRAN_STEPTYP_R
    STEPTYPE          INITIALVALUE_CHECK
    SUBSTEP
    TMPL SECTION    RULE
    Transport this entry by selecting the entry to be entered INITIALVALUE_CHECK from the list, and writing this to an order using the function "Transport Entries".
    Important Note : If you will map again all rules it will give dump . So assume if you have 4 characteristic which are ref. to 0date , so create a rule for one and activate transformation . again do for second one and activate transformation ..do one by one for all ..
    : Activate one by bye each rule and problem will be solved for a moment .
    Another solution If you do not have 0Date or 0Time ref.char of any involved characteristic : simple delete the transformation and do not may this characteristic to any one and activate again ..it will work .
    Regards
    Vikas Sharma
    Rober Bosch GmbH

  • ABAP/4 processor: ASSERTION_FAILED

    Hi BW Experts,
    When we transport one of our Billing DSO and update rules linked to it from Dev to Quality the transport is failing with the below error message.
    09/24/2007  18:35:02  Job started
    09/24/2007  18:35:02  Step 001 started (program RDDEXECL, variant , user ID DDIC)
    09/24/2007  18:35:02  All DB buffers of application server sisbiq02 were synchronized
    09/24/2007  18:35:07  SQL: 24.09.2007 18:35:07 DDIC
    09/24/2007  18:35:07   CREATE UNIQUE INDEX "/BIC/B0001090000~0" ON
    09/24/2007  18:35:07  "/BIC/B0001090000" ("REQUEST", "DATAPAKID",
    09/24/2007  18:35:07  "PARTNO", "RECORD") PCTFREE 10 LOCAL INITRANS 002
    09/24/2007  18:35:07  TABLESPACE PSAPSR3 STORAGE (INITIAL
    09/24/2007  18:35:07  0000000016 K NEXT        0000000160 K MINEXTENTS
    09/24/2007  18:35:07  0000000001 MAXEXTENTS  UNLIMITED PCTINCREASE 0000
    09/24/2007  18:35:07  FREELISTS   004
    09/24/2007  18:35:07  SQL-END: 24.09.2007 18:35:07 00:00:00
    09/24/2007  18:35:10  STDO: Log  could not be written on output device T
    09/24/2007  18:35:20  Replication completed successfully
    09/24/2007  18:35:25  Communication Structure /BIC/CS8ZD2C_O33 activated
    09/24/2007  18:35:36  Transfer Rule(s) 8ZD2C_O33_AA activated
    09/24/2007  18:36:55  ABAP/4 processor: ASSERTION_FAILED
    09/24/2007  18:36:55  Job cancelled
    =================
    When i checked the short dump this is analysis provided...
    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.
    ====================
    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_RSAR_PSA===================CP" or "CL_RSAR_PSA===================CM006"
        "_UPDATE_DIRECTORY_TABLES"
        If you cannot solve the problem yourself and want to send an error
        notification to SAP, include the following information:
        1. The description of the current problem (short dump)
           To save the description, choose "System->List->Save->Local File
        (Unconverted)".
        2. Corresponding system log
           Display the system log by calling transaction SM21.
           Restrict the time interval to 10 minutes before and five minutes
        after the short dump. Then choose "System->List->Save->Local File
        (Unconverted)".
        3. If the problem occurs in a problem of your own or a modified SAP
        program: The source code of the program
           In the editor, choose "Utilities->More
        Utilities->Upload/Download->Download".
        4. Details about the conditions under which the error occurred or which
        actions and input led to the error.
    Did any of you faced this problem
    Can you suggest how to solve the problem... Whether we have to raise SAP message... or any other solution.....
    We are in BI 7.0 with support pack 12.....
    Thanks a lot in advance
    Mahesh reddi

    Hi
    Already one post is there anyway
    If you have checked this message you would know that it got failed after transformation step...i guess its because of some formula in transformation which are causing this problem...you would need support pack 13.
    OSS -1025748
    Thanks
    Tripple k

  • DUMP in program webdynpro  ASSERTION_FAILED  The main program was "SAPMHTTP

    We have a program in webdypro and yesterday we had this dump,but nobody can me tell wath it is mean?.
    Can someone help me? Thanks Flavia
    Texto breve
        The ASSERT condition was violated.
    Anál.errores
        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) "
    Notas para corregir errores
        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_WDR_VIEW_ELEMENT_ADAPTER===CP" or "CL_WDR_VIEW_ELEMENT_ADAPTER===CM01L"
        "DISPATCH_EVENT"
        If you cannot solve the problem yourself and want to send an error
        notification to SAP, include the following information:
        1. The description of the current problem (short dump)
           To save the description, choose "System->List->Save->Local File
        (Unconverted)".
        2. Corresponding system log
           Display the system log by calling transaction SM21.
           Restrict the time interval to 10 minutes before and five minutes
        after the short dump. Then choose "System->List->Save->Local File
        (Unconverted)".
        3. If the problem occurs in a problem of your own or a modified SAP
        program: The source code of the program
         In the editor, choose "Utilities->More
      Utilities->Upload/Download->Download".
      4. Details about the conditions under which the error occurred or which
      actions and input led to the error.
    Usuario y transacción
        Client.............. 300
        User................ "CTACTEPROV"
        Language Key........ "S"
        Transaction......... " "
        Program............. "CL_WDR_VIEW_ELEMENT_ADAPTER===CP"
        Screen.............. "SAPMHTTP 0010"
        Screen Line......... 2
        Information on Caller ofr "HTTP" Connection:
        Plug-in Type.......... "HTTP"
        Caller IP............. "10.10.10.90"
        Caller Port........... 8001
        Universal Resource Id. "/"
    Info posición de cancelación
        Termination occurred in the ABAP program "CL_WDR_VIEW_ELEMENT_ADAPTER===CP" -
         in "DISPATCH_EVENT".
        The main program was "SAPMHTTP ".
        In the source code you have the termination point in line 5
        of the (Include) program "CL_WDR_VIEW_ELEMENT_ADAPTER===CM01L".

    Hello,
    We implement some notes and so far not returned the problem. I do not know if it solved the problem but maybe help you.
    Nota 1522829
    Nota 1070532
    Flavia

  • SAP CRM : Call popup in CUSTOM ACTION (i have a dump : ASSERTION_FAILED )

    Hi to everyone,
    i have a problem to create a popup inside a new custom action in SAP CRM. I have a dump ASSERTION_FAILED.
    Could somebody help me to fix the problem,please?
    Thanks in advance.
    Dario.

    Hi,
    in this case i have to write my code inside a custom action. The problem is that i have no a standard controller and ME instance.
    So i tried to import controller from memory by IMPORT/EXPORT stataments, but when i create popup the system gets a dump :
    ASSERTION_FAILED
    Code is as follows :
        DATA zlc_controller TYPE REF TO cl_bsp_wd_component_controller.
        CALL FUNCTION 'ZCRM_CONTROLLER_GET'
          IMPORTING
            ex_controller = zlc_controller.
        DATA zcl_me TYPE REF TO zl_srqm_inc_incidentovp_impl2.
        CALL FUNCTION 'ZCRM_ME_EHONSAVE_GET'
          IMPORTING
            ex_me = zcl_me.
              lc_controller TYPE REF TO cl_bsp_wd_component_controller,
              lc_view TYPE REF TO cl_bsp_wd_controller.
       IF lr_confirm_popup IS NOT BOUND.
    Message
         MOVE text-t01 TO l_text.
    Title
         MOVE text-tit TO l_title.
        CALL METHOD zlc_controller->window_manager->create_popup_2_confirm
          EXPORTING
            iv_title          = 'TITLE'
            iv_text           = 'TEXT'
            iv_btncombination = if_bsp_wd_window_manager=>co_btncomb_yesno "OK Button
          RECEIVING
            rv_result         = lr_confirm_popup.
        lr_confirm_popup->set_display_mode( if_bsp_wd_popup=>c_display_mode_surrounded ).
        lr_confirm_popup->set_on_close_event( iv_event_name = 'eh_closepopup_at_save'
                                              iv_view = zcl_me ).
        lr_confirm_popup->open( ).
    Thanks.
    Dario.

  • ASSERTION_FAILED in class CL_FAA_TD_AMD_MNGR

    Hi All,
    I run a job for the report RAKOPL02.
    I get a Abort message (error).
    Please helop how to resolve it ASAP.
    Job started
    Step 001 started (program RAKOPL02, variant &0000000000004, user ID
    ABAP/4 processor: ASSERTION_FAILED
    Job cancelled
    Regards,
    Vaibhav

    The user faced a problem while running a report RAKOPL02.
    When we checked in SM37 it showed that the job is cancelled because of the error 'ASSERTION_FAILED". We checked in ST22 and found the blow mentioned steps in Error Log :
    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.
    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_FAA_TD_AMD_MNGR============CP" or "CL_FAA_TD_AMD_MNGR============CM00A"
        "IF_FAA_TD_AMD_MNGR~SET_TMINTRVL"
    Hope this detailed information helps.
    Regards,
    Vaibhav

  • 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.

  • 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

Maybe you are looking for