Register Login

SAP BASIS Dumps and Solution

Updated Aug 27, 2018

Hello Experts,

What are some of the common dump errors that can turn up during transactions and how do I solve them?

Thanks in advance.



  • 28 Apr 2016 12:31 pm Abhijeet Mudgal Best Answer

    Following are a number of errors that you can get along with their corresponding solutions


    This usually happens when any transaction has fifty or more nested “CALL SCREEN”. The solution is to redesign your transaction to prevent that many nested calls. Note that there ia a distinction between CALL SCREEN and SET SCREEN. While CALL SCREEN creates a new stack and puts the entry in it,  SET SCREEN only navigates between screens. 


    There is not help text available for the above dump. All we can say is that this either happened because the release of the kernel is not the same as the release of the database, or that the text was deleted for some reason. You can look for further information in the note system. 


    This typically shows up because of the SAPGUI. It is likely that a RAISE statement came up in the program CL_PO_ITEM_HANDLE_MM=======CP and the condition FAILURE was returned. The process was terminated because no superior program took up the exception. 


    This happens when you try to execute a statement but you end up with a deadlocked session since there is another session that had the same resource locked. There are two possible options to take care of this error: you can either wait a little while for the other session to close and re execute the statement, or you can execute a ROLLBACK since the last time the session was saved i.e. COMMIT was used. 


    This means that your DBA has decided to start a SHUTDOWN IMMEDIATE command. Oracle swill shut down completely and any active operations will be terminated. There is no way to stop this command so the best you can do is wait until Oracle has been restarted by the DBA. 


    This error means that a user context or an internal session has been trying to use more than 2 GB of main memory. Since 32-bit variables are frequently used, the Database puts a cap on the stems at 2 B. Consider a way to run a session that requires lower memory consumption. This includes trying to use unsigned 32-bit variables that allow up to 4 GB of transaction space. 

    Consider if the way you are using the application is in fact the way in which it was intended to be used, or if you have selected too much data. Moreover, check and see if the consumption of memory in your system and in the application depends on any parameters that you have customised. Finally, the application may not actually be a very memory economical one, especially when there are transactions that run for long times. 

    A tool named “Memory Inspector” is available for use in these situations that decides and lists ranked lists of large internal tables and also indicates discrepancies between large objects. The use of this tool might be useful.