ASSERTION_FAILED when Activate a DTP

Question

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.

Answer 1

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.