Skip to Content
Technical Articles
Author's profile photo Alfonso Rodríguez Pérez

Break point for SELECT statement with Table Filter


In some occasions we need to find exactly where a SELECT statement is done for a particular table.

We can use breakpoint for SELECT statement but, most probably, the debugging session can be hard due to the number of hits we can get.

We can use some traces transaction like ST05 or ST12, but we need to switch ON/OFF the trace and then analyse the result.

To go straight forward and find exactly the place in the code where table, or a group of them, are being involved in a SELECT statement we can use Filter Criteria for the Breakpoint.



Imagine that we want to identify where tables EKKO and EKPO are being selected during execution of Transaction Code  ME23N – Display Purchase Order


Start a debugging session:


Press ENTER:


Run TCode ME23N and press ENTER:


Just after debugging environment is available, create a Breakpoint for SELECT statement:


Now go to “Break./Watchpoints” tab:


Select the line for Breakpoint created and press “Define Filter”:


Select RSTPDA_SCRIPT_BP_SQL_DBTAB filter option:


Now write the table you want to focus on:


Actually this is a Select Options, so you can decided the tables as you wish:


Then, accept the selection criteria. You can decide to save the breakpoint but although breakpoint will be available for next run the filter is removed so just put it back if you need to debug again:


Go to Desktop 1 tab:


Press F8 … Hit for EKKO reached!


Press F8… again another EKKO selection:


Now EKPO hit!:


And another EKPO selection found!:



We can save much time to find out where a particular table is used in a SELECT statement or where to develop an enhancement after the SELECT.

Finally mention that his approach is also working when SELECT statement is built with dynamic table name:


Alfonso Rodríguez Pérez.
SAP ABAP Consultant.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Bärbel Winkler
      Bärbel Winkler

      Thanks for this tip, Alfonso!

      I have a hunch that this will come in very handy in future cases of "tracking down an error".



      Author's profile photo Sandra Rossi
      Sandra Rossi

      I didn't pay attention to that "define filter" option. Up to know, I could achieve the same result by going to the "script" tab, run directly the script you show (RSTPDA_SCRIPT_BP_SQL_DBTAB), enter the table name(s), continue, and wait until the debugger stops at the right place. Do you know how this "define filter" option is articulated compared to the "script" tab?

      Author's profile photo Alfonso Rodríguez Pérez
      Alfonso Rodríguez Pérez
      Blog Post Author

      Hi Sandra,

      Basically what the Blog describes is a short way to do what "Script" Debugger can do for script RSTPDA_SCRIPT_BP_SQL_DBTAB.

      You can do the same from "Script" tab by using RSTPDA_SCRIPT_BP_SQL_DBTAB... Important hint is that you need to use "Breakpoint Reached" in Trigger options of Script, then press the icon change and then create a specific Breakpoint for statement SELECT. But DO NOT create the Breakpoint for SELECT statement from top menu of debugger as described in the blog.

      A good blog to start with Script Debugger:




      Author's profile photo Sandra Rossi
      Sandra Rossi

      In the script tab, when you select RSTPDA_SCRIPT_BP_SQL_DBTAB, I'm pretty sure the breakpoint at SELECT is automatically set (it's part of the options when you create a script, you can see it in the "XML comments" of the source code).

      Author's profile photo Alfonso Rodríguez Pérez
      Alfonso Rodríguez Pérez
      Blog Post Author

      OK... May be I don't catch you...

      Just with the "Load Script" RSTPDA_SCRIPT_BP_SQL_DBTAB, the break point is not set.

      Have you tested it? you can use same example of the Blog description ME23N, load the Script RSTPDA_SCRIPT_BP_SQL_DBTAB...



      Author's profile photo Sandra Rossi
      Sandra Rossi

      You're right. I made a mistake in the script name. The one I frequently use is RSTPDA_SCRIPT_BP_SELECT_TAB. It does the same thing (?), stops at SELECT by default.

      I think that "Define Filter" is more convenient than selecting the script and run it.

      I will now use your method. Thanks! 🙂


      Author's profile photo Alfonso Rodríguez Pérez
      Alfonso Rodríguez Pérez
      Blog Post Author

      Hi Sandra,

      Thank you for the test and your feedback.



      Author's profile photo eva grey
      eva grey

      A very helpful post. 

      Author's profile photo Matthew Billingham
      Matthew Billingham

      I use SQL trace to find out where in the code a table is hit. Then set a breakpoint there. However, the blogged approach is a single step, so I guess an improvement.

      Does it work with persistent classes though?

      Author's profile photo Alfonso Rodríguez Pérez
      Alfonso Rodríguez Pérez
      Blog Post Author

      Hi Matthew,

      The answer is yes, as long as there's a SELECT statement in Base Class of persistent family classes ZCB_xxxxxx

      Actually I've tested myself thanks to this blog:


      Sorry, it seems I can't paste my screenshot in the answer.





      Author's profile photo Augusta Liliana
      Augusta Liliana

      Brilliant post! I found this post very great. Keep updating us. 

      Author's profile photo Joachim Rees
      Joachim Rees

      Very nice post about "filtering" of breakpoints - have not used it yet, but will do so in the future!

      Author's profile photo Chandrakant Mohanty
      Chandrakant Mohanty

      Very nice blog, and its really handy too. Thanks for making this blog and saving our time and importantly learning over looked things.

      Author's profile photo Diego Concha Hombrados
      Diego Concha Hombrados

      You're a really crack!!