Skip to Content
Technical Articles

Break point for SELECT statement with Table Filter

1. OVERVIEW

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.

 

2. TEST CASE

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!:

 

3. CONCLUSION

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:
https://help.sap.com/viewer/cfae740a0a21455dbe6e510c2d86e36a/7.3.19/en-US/fceb39c4358411d1829f0000e829fbfe.html

 

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

12 Comments
You must be Logged on to comment or reply to a post.
  • 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?

    • 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:
      https://blogs.sap.com/2010/12/14/abap-debugger-scripting-basics/

       

      Regards,

      Alfonso.

      • 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).

        • 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…

          Regards,

          Alfonso.

      • 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! 🙂

         

  • 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?