SQL_CAUGHT_RABAX Error Dump
In the dump file in “What Happened” section, the cause has been described.
Dump "TSV_TNEW_PAGE_ALLOC_FAILED" means because of huge selection of data, you had shortage of memory.
Using the similar selection criteria to exclude 1 sales order number with table EBKN check directly via transaction SE16, for checking if it is not caused by SQL or ABAP Program error.
With the same amount selection of data, here it means, the dump also occur even direct access database.
If only 1 sales order from the selection is excluded , the dump details look as given below:
* Zugriff über EBKN
IF ti_imkeys IS INITIAL.
|>>>>>| SELECT (fs_ebkn-fields)
APPENDING CORRESPONDING FIELDS OF TABLE tebkn
UP TO i_selection_limit ROWS
WHERE mandt EQ sy-mandt
AND kostl IN ti_kostl_range
AND aufnr IN ti_aufnr_range
AND anln1 IN ti_anln1_range
AND anln2 IN ti_anln2_range
AND vbeln IN ti_vbeln_range
AND vbelp IN ti_vbelp_range
AND nplnr IN ti_nplnr_range
AND ps_psp_pnr IN ti_ps_psp_pnr_range
AND loekz IN ti_ebkn_loekz_range
For solving this kind of dump which was not caused by SQL syntax or ABAP Programming error, 3 types of resolution approach are there. This is because with the same selection criteria via transaction SE16 the dump can also reproduce with direct access to table.
1. Please minimize your selection criteria, from application point of view.
For example, selection criteria "Sales Order" not equal to 1 sales order number means except excluded sales order number all data in the table EBKN. Than including all data from table EBKN and excluding only the purchase requisition related to 1 sales order number, it is more logic to fill in this field with intended sales order range to assign and process the relevant purchase requisition.
2. To increase memory or maintain suitable memory, a discussion should be made with your Basis administrator.
3. Purchase requistion table EBAN and EBKN not with huge data when Planning Archiving for the old/unwanted purchase requisitions. For Purchase Requisition Account Assignment table EBKN stored data.
From application point of view, solution (1) will be recommended as it is more logical unless specific business needs. From transaction SE16(direct access), it clearly show, the short dump is caused by lack of memory due to huge selection of data from table EBKN and not caused from SQL syntax or ABAP program error.