Skip to Content
Author's profile photo Dominik Krämer

Differences between watchpoints and conditional breakpoint & other debugging tricks


Watchpoints are generally used when you need to find, at what point in time a variable is changed.

The debugger stops as soon as the variable is changed and any additional condition specified with the watchpoint is true.

The watchpoints can be set directly in the debugger in the tab “Break./Watchpoints”
subtab “Watchpoints”.


While creating the watchpoint you can specify the variable you want to check and any additional condition which

must be able to be interpreted as either abap_true or abap_false. Some examples can be found by clicking on the

button next to the condition entry.


Please note that putting a watchpoint on an internal table will dramatically decrease the performance.

Internally a copy of the object is generated which leads to higher memory consumption.

Conditional Breakpoint (available as of SAP NetWeaver 7.0 EHP2)

Conditional Breakpoints should be used, if you know the area on which you need to focus on
during debugging, but this area is in eg. an loop over an huge table. Rather to step by step press F8

until you reached the desired entry you can set an conditional breakpoint.

To create a conational breakpoint goto the line you are interested in and right click on the existing breakpoint.

From the context menu you can then choose to create the condition.


Then you can specify the condition you need:


The breakpoint will then only stop if the condition evaluates as abap_true.

Debugging Popups

From a popup you cannot start the debugger, as the command field is not avaiable. However there is a small workaround here.

All you need to do is to create a shortcut with type “System command”.


Then you can always drag & drop the now created file to the popup which will enable the debugger.

If you want to be able to use the created file for all your systems, open it in Notepad and delete

everything expect the block beneath [Function].

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Thanks for the information. The conditional breakpoint concept was new to me.

      But I still don't see any advantage of conditional breakpoint over a conventional watchpoint. Can you please throw some light?

      Author's profile photo Clemens Li
      Clemens Li

      Let me just guess:

      You need a watchpoint for SY-SUBRC <> 0. This may be triggered from various points in execution. If you put a conditional breakpoint with condition SY-SUBRC <> 0 directly after a suspicious function call, then the break only occurs if the function is called and an exception is raised.

      You may think of more situations where a watchpoint might be triggered more often than needed.



      Author's profile photo Former Member
      Former Member

      Right, thanks 🙂

      I face similar problem with breakpoints with commands too. Is there any fix for that?

      Like, when I am trying to trace at what point the database is updated, I generally put a break point on command ( Insert dbtab / update dbtab / modify dbtab etc. ) Now, this starts giving me breakpoints at very deep levels of function calls. So, I have to keep shuffling between activating and deactivating breakpoint for the piece of code I need to check.

      Can I make it enabled for one particular program?