Scribd
Upload
161 views

How To Analyze An Error Message in Debug

This document describes how to analyze error messages in debug mode in SAP. It explains that error messages do not always provide enough context to identify the cause. It recommends setting a watchpoint on the SY-MSGNO and SY-MSGID variables to trigger a debug stop at the exact point where an error message is generated. This allows inspecting internal tables and code to understand why the error occurred. The example demonstrates generating an error, setting a watchpoint on SY-MSGNO, and stopping debug at the function module call that is triggering the message.

Uploaded by

Venkatesh Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
161 views

How To Analyze An Error Message in Debug

This document describes how to analyze error messages in debug mode in SAP. It explains that error messages do not always provide enough context to identify the cause. It recommends setting a watchpoint on the SY-MSGNO and SY-MSGID variables to trigger a debug stop at the exact point where an error message is generated. This allows inspecting internal tables and code to understand why the error occurred. The example demonstrates generating an error, setting a watchpoint on SY-MSGNO, and stopping debug at the function module call that is triggering the message.

Uploaded by

Venkatesh Yadav
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 4

How to analyze an error message in debug

Very often an error or warning message is not clear or does not provide the necessary details to find the exact
cause of the error.
A classic example is the error message 'The date 00.00.0000 is not convertible (please correct)' which can be
triggered in several transactions. When this message is triggered by MRP or in transaction MD04, it does not
specify exactly what is the planning element for which the error happened.
Another typical issue is a custom error message being triggered by an exit or BAdI, but you don't know exactly
which exit or BAdI is triggering the message.
For such cases, there is a very simple trick to find exactly where the error message is triggered.
Lets see a very basic example. I'll get into transaction CO02 and enter a production order that does not exist.
The following error message will be triggered:

The last three digits are always the message number and the rest is the message ID.
When a message is triggered by the system, the message ID is stored on SY-MSGID and the message
number is stored on SY-MSGNO
Now I want to know exactly where this error message is triggered.
Open transaction CO02, enter a production order that does not exist on the database. Type '/H' on
the command to open debug and press enter.
Click the button 'Watchpoint' to create a new watchpoint.

Generated by Jive on 2015-10-16+02:00


1

How to analyze an error message in debug


You will get the following screen, where you will create a watchpoint for SY-MSGNO, where the value
of the variable is '017'. In some cases, you don`t know the message number, so you can leave the
condition empty. In such case, system will stop on every message, instead of goig directly to the
desired message.

Confirm and press F8 to continue with the program execution.


System will stop exactly on the point where the error message is triggered.

Generated by Jive on 2015-10-16+02:00


2

How to analyze an error message in debug

Here we can also check the values of the internal tables and see why the error message is triggered. We can
also see that the message is hardcoded as an error, because there is an 'e' before the message number.
Similarly, It would be possible to set a watchpoint for SY-MSGID, where the value is equal to 'CO'.
On this example, I can see that the error is happening after function module CO_DB_HEADER_READ is
called. This is the function module where the order header is read from the database, so I can get deeper into
the code to find exactly where the order is read.
With a little knowledge of code we can find the solution of problems that we would spent hours researching and
checking on the documentation.
Check also the following document for a quick step-by-step to analyze authorization in debug:
How to analyze authorization issues in debug

Generated by Jive on 2015-10-16+02:00


3

How to analyze an error message in debug

Generated by Jive on 2015-10-16+02:00


4

You might also like