Different kind of SAP ABAP dumps

 Different kinds of dumps in SAP ABAP:

1. RAISE_EXCEPTION :

Function module(FM) raise an exception that was not intercepted by a program higher up in the stack and if it occurs in a customer program, then the developer needs to handle the exception in the calling program. This happens in a SAP program, then it may be an unexpected situation. Then this is often useful for this kind of failure to look at the values of sy-msgid and sy-msgno. Then we should also search for notes containing the message id and number, and/or important keywords from the 'How to correct the error' section.

2. RFC_ATTACH_GUI_FAILED :

This commonly happens when an RFC(Remote function call) enabled function module is run, that then goes on to do something connected with screen handling. It does not have a screen and it fails. It can also happen if SAP GUI [or components of it, such a BEX] have a problem, or are incorrectly installed.

3. LOAD_PROGRAM_LOST :

Program we were running was changed while we were running it. In a BI [& other similar environments] this happens quite often if you are in sections of the system that generate code -such as developing routines in transformation. If there is not much to do but restart the transaction we were running. Then to avoid this in RSA1, if you are doing lots of complicated development, then it is a good idea to restart the transaction from time to time.

4. DBIF_RSQL_SQL_ERROR :

Indicates a problem occurred in the database. We may find more information in the system log via tcode SM21. Exact same nature of the failure is usually seen in the 'How to correct the error' section. If this occur in the standard SAP code, then there may be a corrective note. May be connected with database set up, so if the cause is not obvious [like a malformed dynamic SQL from one of your own programs], then it may be worth talking to your basis team.

5. MESSAGE_TYPE_X :

This message comes up, then it means the program met a situation that it just did not know what to do with. In the 'Error Analysis' section you will see the short & long text of the error message. If sometimes the error indicates inconsistent data, sometimes as Rob Dielemans points out, this can be used deliberately during the development process.

During development we simply want to know if a certain piece of code gets executed at all [usually background stuff, like workflow], we just coded a type X message with same value such as sy-uname other variable we are interested in. It is a very good way to exactly find out the value of a parameter when differences can occur in debugging.

6. ASSIGN_TYPE_CONFLICT :

Most likely a programming error. Message indicated that an ASSIGN is occurring that is going to an incorrectly typed field symbols. Check if the Source Code extracted to see exactly where the problem occurs & carefully check that the typing of the object matches.

7. OBJECTS_OBJREF_NOT_ASSIGNED_NO :

Attempt made to access an object [the class type is given] that had not been instantiated. Most likely a programming error.

8. TSV_TNEW_PAGE_ALLOC_FAILED and MEMORY_NO_MORE_PAGING :

This indicates that our process ran out of memory. It may be a programming issue - check the size of an internal tables & how much data you are selecting. Perhaps there are eternal loop that just keeps adding to a table. It may be a hardware issue - that there simply is not enough memory available. Error are hard to track down, as the place where memory are actually exhausted may vary. What can we do shows the amount of memory of the various kinds that are available. May be information in the 'Error analysis' section shows exactly which internal table could no longer stretched to contain more data.

9. UNCAUGHT_EXCEPTION :

The object oriented equivalent of RAISE_EXCEPTION. This means that a class based exception was raised in a method or function module or form that was not caught higher up. Usually this indicates a programming error. I have seen attempts to fix this, using CATCH cx_root & then continuing processing. This is a very bad way of fixing the error, as this ignores the cause of the exception. If we Ignore an exception like this is like ignoring non-zero sy-subrc.

10. COMPUTE_INT_ZERODIVIDE :

Attempt has been made to divide by zero. Either a data or programming error. In fact, it is always a programming error as any division should always check if the denominator is zero & correct raise an error condition if it is.

11. RFC_NO_AUTHORITY:

The user that tried to execute an RFC enabled function module, via RFC and was not authorized via authorization object S_RFC to run the function module. Name of the function module(FM) is in the Short Text. Let's know the name of the user id is in the 'What happened' ?section.

12. TIME_OUT :

This is a basic setting that sets a limit for the run time of a transaction / report -- typically 15 minutes. If a dialogue process exceeds this limit, then the  kernel spots it & stops the program with a TIME_OUT dump. Common causes are:

The User selecting too much data - like all companies, or all controlling areas. Then a programming error resulting in a endless loop which is Inefficient programming. For ex: using STANDARD tables instead of HASHED or SORTED, loops within loops, selecting the same data again and again etc..,

Most common solution is to extended the allowed run time. However, this should be the very last resort, as it only fixes the symptom, not the root cause & as data volumes increase, we are likely to hit the new limit eventually. This is much better to fix the program. Where users select too much data, for ex: the selection screen can be adjusted to prevent this. If a wide selection is needed, then perhaps the program can be run in background - and if necessary, to populate a database table that can be reported on.

Hope this help. Thank you everyone.