What does it do? This statement defines a breakpoint>. The addition ID> controls the activation. Without the addition ID >, the breakpoint is always active. Breakpoints in Dialog Processing> If the program reaches an active breakpoint in dialog processing>, the program execution is interrupted and the system branches to the ABAP Debugger. An inactive breakpoint is ignored and the program execution continues with the statement after BREAK-POINT>. Breakpoints in Background Processing> During background processing>, program execution is not interrupted. When the program reaches a permanently active breakpoint (the addition ID> is not used), the entry Breakpoint reached> is written to the system log along with the program name and the location of the breakpoint in the program. Activatable breakpoints (where the addition ID> is used) are ignored. The program execution continues in both cases with the statement following BREAK-POINT>. Breakpoints in Updates> During synchronous> and asynchronous updates> in an update session>, the behavior depends on the setting of the ABAP Debugger:
If ABAP Debugger is not set to update debugging>, a breakpoint behaves as in background processing.
If ABAP Debugger is set to update debugging>, a breakpoint behaves as in dialog processing. The update is executed in a dialog work process of the current ABAP_ASINSTANCE . In local updates>, a breakpoint behaves as in dialog processing. Breakpoints in RFC Processing> In RFC processing>, the system stops at an active breakpoint and branches to the ABAP Debugger of the SAP GUI whenever an RFC> dialog interaction> is possible. The ABAP Debugger in the ABAP Development Tools (ADT)> can also be displayed if no dialog interaction is possible. Breakpoints in ICF and APC Processing> In ICF processing> and APC processing>, the system stops at an active breakpoint and branches to the ABAP Debugger of the SAP GUI only when external debugging is enabled. When programs or procedures are called in ICF processing and APC processing, they are executed in the context of the service context and their breakpoints behave accordingly. External debugging can be switched on for a limited time period (by default two hours) using transaction SICF>> or by setting an external breakpoint in the ABAP Editor. If external debugging is not switched on, the breakpoints behave as in background processing. The ABAP Debugger in the ABAP Development Tools (ADT)> can also be displayed if external debugging is not enabled. Breakpoints in ABAP daemon Processing> In ABAP daemon processing>, the system stops at an active breakpoint and branches to the ABAP Debugger of the SAP GUI only when external debugging is enabled. This also applies to non-dialog users and in callback routines. Breakpoints in System Programs> In system programs, system modules, system subroutines, and system function modules whose name begins with %_, the statement BREAK-POINT> is only respected if system debugging> is switched on in the ABAP Debugger (using the Settings> menu or by entering /hs> in the command field of the system toolbar>). Otherwise, breakpoints are ignored.
Latest notes:
A breakpoint in SELECT>> loops can raise an exception due to the loss of the database cursor>. This is because a database commit> may be triggered during debugging.