Ошибка sap abap runtime error

Whenever SAP comes across an issue that causes it to stop processing it generates an ABAP Runtime Error. A basic example of this would be a divide by zero but there and many such errors defined in SAP such as DBIF_RSQL_INVALID_REQUEST Invalid Request.

The runtime error would be presented immediately if executing a dialog process but can be recovered any time using transaction ST22. All runtime errors that happen during a background or RFC process are also available via tcode ST22.

The runtime error contains all the details about the type of error as well as the contents of the program variables at the point of the error. for example here is an example of the description you might see for DBIF_RSQL_INVALID_REQUEST.

What Happened? The current ABAP/4 program terminated due to an internal error in the database interface. What can you do? Make a note of the actions and input which caused the error. To resolve the problem contact your system administrator. You can use transaction ST22 (ABAP dump analysis) to view and administer termination messages, especially those beyond their normal deletion date. Error analysis.

In a statement, an invalid request was made to the database interface when accessing the table “EKKO”.

SAP Runtime error transactions and ABAP programs

ST22 –ABAP runtime error
RSLISTDUMPS – List All Runtime Errors and short description
RSSHOWRABAX – Program associated with ST22

SAP Runtime error tables 

SNAP – ABAP/4 Snapshot for Runtime Errors (ST22 list)
SNAPTID – ABAP Runtime Errors – Uses SNAPT as a text table so Includes first text line(TLINE) 
SNAPT – ABAP Runtime Error Texts
SNAPTTREX – Exception table for translation

Runtime Error categories (SNAPTID-CATEGORY)

Field: SNAPTID-CATEGORY
Domain: S380CATEGORY

• I Internal Error
• R Error at ABAP Runtime
• Y Error at Screen Runtime
• D Error in Database Interface
• A ABAP Programming Error
• F Installation Errors
• O Resource Shortage
• E External Error
• U End User Error
• K No Error
• S ST Runtime Error
• J Internal ST Error
• X XSLT Runtime Error& Text Include (no Short Dump, only Text Module)
• & Text Include (no Short Dump, only Text Module)
• B ITS Error
• Q Error in Open SQL
• – Unclassified Error

Most common SAP runtime errors

Below is a list of some of the more common runtime errors including a link to full details of the error and what causes it.

DBIF_RSQL_INVALID_REQUEST

MESSAGE_TYPE_X

TIME_OUT

OPEN_DATASET_NO_AUTHORITY

CONVT_NO_NUMBER

GETWA_NOT_ASSIGNED

TSV_TNEW_PAGE_ALLOC_FAILED

LOAD_PROGRAM_CLASS_MISMATCH

LOAD_PROGRAM_INTF_MISMATCH

• 31 Oct 2013 5:57 am Rohit Mahajan

  Run transaction ST22 to get the details of the error, and find the one for your particular run.
  It will show the program line where the error occurred.
  Find ‘pernr’ to get the employee’s pers.no.
  Then determine the cause of error
  as below:
  a)In transaction SE38 display the program as above. Go to the line where the error occurred,
  b)Set break point just before the line or at the line.
  c)Re-run the payroll for the employee.
  d)When the program stops at the breakpoint, check all the relevant data.
  e)Where required, execute one line at a time, so that you can understand what is happening.

  Then you should be able to find the reason for the error.

  If the problem is in a custom ABAP function, then consult the programmer.

  If the problem is in a SAP program object,
  1)find OSS notes relevant to the problem.
  2)If there are any, apply the notes in the dev.system, import the employee’s data to the dev test client. Repeat the payroll as above and check if the problem is fixed.
  3)If not found, report the error to SAP with an OSS message and all relevant details of data used, transaction, which pay period, expected results, etc.; follow up with SAP for a resolution

When a report or module dumps, the reason is mostly quite obvious. Some runtime errors are «catchable», but when not caught they will stop your report. If you are the user causing the dump, there is a «Debug» button available to you to start the debugger.

This is «Post mortum» debugging — where you know the patient has already died — but having a look around in the debugger can be very useful. Catchable runtime errors are handled with CATCH SYSTEM-EXCEPTIONS using the name of the runtime error. Here’s a list of runtime errors with a brief explanation of what to look out for.

To detect semantically related runtime errors using a common name, they are combined into exception groups. You can handle catchable runtime errors in an ABAP program using the following control statements:

CATCH SYSTEM-EXCEPTIONS exc1 = rc1 ... excn = rcn.
  ...
ENDCATCH.

The expressions exc1 … excn indicate either a catchable runtime error or the name of an exception class. The expressions rc1 … rcn are numeric literals. If one of the specified runtime errors occurs between CATCH and ENDCATCH, the program does not terminate. Instead, the program jumps straight to the ENDCATCH statement. After ENDCATCH, the numeric literal rc1 … rcn that you assigned to the runtime error is contained in the return code field SY-SUBRC. The contents of any fields that occur in the statement in which the error occurred cannot be guaranteed after ENDCATCH.

If you don’t know which exception class to catch, you can use OTHERSto catch all possible catchable runtime errors. Do beware: not all runtime errors are catchable !

CATCH SYSTEM-EXCEPTIONS others = 4.
  ...
ENDCATCH.

Catching the error that would cause a dump — TRY — ENDTRY

One example problem that can not be caught with CATCH SYSTEM-EXCEPTIONSis the example below:

APPEND 'MSGNR = 123' TO options.
APPEND 'ORX' TO options.  "<== ERROR HERE
APPEND 'MSGNR = 124' TO options.
* Dump: SAPSQL_WHERE_PARENTHESES
*       CX_SY_DYNAMIC_OSQL_SYNTAX

CATCH SYSTEM-EXCEPTIONS others = 4. 
  SELECT * FROM t100
    UP TO 1 ROWS
    WHERE (options).
  ENDSELECT.
ENDCATCH. 

The solution for this is the TRY - ENDTRY block, which is a much more precise version of the CATCH SYSTEM-ERRORS. The above example solved:

TRY.
    SELECT * FROM t100
      UP TO 1 ROWS
      WHERE (options).
    ENDSELECT.
  CATCH cx_sy_dynamic_osql_error.
    MESSAGE `Wrong WHERE condition!` TYPE 'I'.
ENDTRY.

The exceptions hierarchy

So which exceptions are available ? And which ones can be caught with CATCH ? Note that exceptions live in exception classes, which adhere to the naming convention CL_CX_*. There’s many examples available through transaction SE24 class builder. Also note that there is a class-hierarchy on the exceptions. The top op the hierarchy is class CX_DYNAMIC_CHECK, below is you could finr e.g. CX_SY_CONVERSION_ERROR and below that the CX_SY_CONVERSION_NO_NUMBER can be found. If you want to specifically catch a number conversion error, the ...NO_NUMBER exception is your candidate of choice. It it’s all possible conversion errors you are interested in catching, the .._ERROR candidate is better, and so on. This example doesn’t care what exception is caught — as long as it is caught:

DATA: lv_char TYPE c LENGTH 50,
      lv_num TYPE n LENGTH 6,
      lo_error_ref TYPE REF TO cx_dynamic_check.

TRY.
    lv_num = 123.
    lv_char = 'Test'.

    lv_num = lv_char. "<= No dump (lv_num = 000000)

    IF lv_num = lv_char. "<= DUMP! - uncatchable !!
    ENDIF.

  CATCH cx_dynamic_check INTO lo_error_ref.
    MESSAGE `Conversion error` TYPE 'I'. "<= Catches nothing...
ENDTRY.

Normally the dump that is produced when a conversion error happened will also state the exception that should/could be used to CATCH it. However, there is an exception — so I found. The IF statement above produces a dump, which can not be caught.

The solution for this is a bit of leg-work. With DESCRIBE FIELD ... TYPE ... the type of the field can be determined. If it is N, the lv_CHAR variable better only contains numbers.

So SAP — why is the conversion done in an IF statement not catchable ?

Following on from a previous article ‘ABAP Programming With The ABAP Workbench – The Tools You Must Learn And Master‘, where we went through how you can use some of the SAP workbench development tools to quickly analyze our ABAP code and improve your program performance; we will now learn how to troubleshoot our ABAP code when it returns a runtime error.

There are many reasons why a run-time error can occur such as un-handled exceptions, a resource or system problem or an error in coding. Let’s look a little deeper…

Tools for Troubleshooting Your ABAP Code

System Logs (TCODE – SM21)

When faced with a program that crashes, developers end up spending a lot of time debugging ABAP code to find and trace what went wrong. But they should know that SAP records all the warnings, exceptions and system errors in the System Log. So, when we get an error we can make best use of time by taking a good look at the System Logs first to help find and correct the errors in our code quickly and easily.

To view the System Logs goto transaction SM21.

These are the different types of logs created by system log:

1. Local System Logs

2. Remote System Logs

3. All Remote System Logs

4. Central System Logs

In this tutorial we will see how to view the Local System logs, but the process is same for the other types of log files.

Click on the System Log menu button, select ‘Choose’ and you will see the different types of logs. Select ‘Local system logs’.

 In the selection screen you have the option to provide the period, user, transaction, process and the program class.

After entering the details hit the F8 button or you can click on the ‘Reread System logs’ button provided at the top of the screen.

After execution is completed you will have a table with the system log entries depending on your selection criteria.

By double clicking on a specific entry you can view the detailed information.

Always use SM21 as a starting point to analyze an ABAP program for dumps and errors.

ABAP Runtime Error/ ABAP Dump Analysis (TCODE – ST22)

A runtime error is triggered when there is an un-handled exception or a system error in an ABAP program. By the help of this recorded runtime error you can pinpoint the problem and get to the solution quickly. To start the ‘ABAP Runtime Error’ go to Transaction code ST22.

You will find the standard option in the selection screen i.e. ‘Today’ and ‘Yesterday’ with the total number of run-time errors that have occurred during these periods.

In the ‘Own Selection’ section you can provide your own filters such as date, time, user and other parameters.

At the bottom of the screen you will find three important check boxes which by default are not selected.

1. With information on Exception/Short Text of Runtime Error: Selecting it you can see the ‘short text’ of the runtime error with concise information. You can then navigate to the ‘Long Text’ from there
2. The program affected: Selecting it you can see the program affected.
3. Program and associated application components (long runtime): Selecting this check box you can see detailed in-depth relating to the program and its associated components.

If the runtime error is occurred today then you can press the push button ‘Today’ to go to the list of runtimes errors today.

Double clicking on a row will take you to the ‘Runtime Error Long Text’

Short Text: It gives us a short description of the runtime error.

What Happened? : This section gives the name of the program which requires correction.

What Can You Do? : Here you can see some suggestions.

Error Analysis: This section often provides really detailed information about the possible causes of the runtime error.  This section is really important and you should go through it to get a head-up about the exact cause of the error.

How To Correct The Error: Here you will find some information on how you can possibly correct this error. Often by following the steps given in this you can correct your code or at least it will point you in the right direction.

Source Code Extract: This section gives the exact line number on the code where the runtime error was triggered. By double clicking on this you can navigate to the source code. This is very useful because it saves a lot of your time and without debugging you know the location of the bug which caused the runtime error.

The other sections provide you information regarding the list of variables and the programs affected.

In this tutorial we have seen that it is always a good idea to first analyze the logs and dumps before just blindly debugging your ABAP program which in turn helps you solve your coding issues in the least amount of time possible.