We are getting frequent ABAP short dump of the type 'Assertion Failed' in our application. When I check in ST22 I get the following details.
Information on where terminated
Termination occurred in the ABAP program "CL_WDR_TABLE_DATA_PROVIDER====CP" -
The main program was "SAPMHTTP ".
In the source code you have the termination point in line 74
of the (Include) program "CL_WDR_TABLE_DATA_PROVIDER====CM00A".
Source Code Extract
55 if m_fixed_row_count <> c_no_fixed_row_count. 56 data row_count type i. 57 58 " Rows that are in the table from FIRST_VISIBLE_ROW 59 row_count = m_fixed_row_count - e_first_visible_row. 60 " but max. the number of rows that can be displayed at one time 61 if m_visible_row_count <> -1 and 62 m_visible_row_count < row_count. 63 64 row_count = m_visible_row_count. 65 endif. 66 67 " Check if RowCount > FirstActualRow + # of Context Elements 68 " * m_wd_table 69 " * ROW_COUNT 70 " * DATA_SOURCE 71 " * FIRST_ACTUAL_ROW 72 73 * assert lines( e_row_data_tab ) = row_count. >> assert lines( e_row_data_tab ) >= row_count. 75 endif. 76 77 if m_show_lead_selection = abap_true. 78 e_lead_selection = get_lead_selection( ). 79 else. 80 clear e_lead_selection. 81 endif. 82 endmethod. "get_visible_table_data####
A resolution will be highly appreciated.
Are you setting the visibleRowCount property of the Table? It seems like the error is produced by having more rows to display than the visibleRowCount will allow. Check to make sure your application isn't trying to control rowCount dynamically and supplying some incompatible values. Otherwise consider searching for support notes and/or entering a support ticket as this could be an internal rendering error.
I ran into a similar issue last Friday. It took me more than one hour to debug. Finally my finding in my project code is: I called apply_filter() of the Web Dynpro table's method handler, before I bound data to the context node which is used by the table. The number of records bound to the context node is less than the number of records at the time of the apply_filter() call, and thus the exception.
So finally my solution is to always call apply_filter() after new data is bound to the context node. This way my project works fine.
Not sure if my situation is similar to yours, but you can have a try. Hope that helps.