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

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.

Assigned Tags

      18 Comments
      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".

      Cheers

      Bärbel

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

       

      Regards,

      Alfonso.

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

      Regards,

      Alfonso.

      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.

       

      Regards,
      Alfonso.

      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:
      https://blogs.sap.com/2012/04/18/abap-persistent-object-services-demystified/

       

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

      Regards,

      Alfonso.

       

       

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

      Author's profile photo Jigang Zhang 张吉刚
      Jigang Zhang 张吉刚

      Alfonso Rodríguez Pérez

      Thanks for sharing this. It's working without any filter for DB selection. Could you please let me know why it's not stopped when setting a filter with any specific table name? SAP_BASIS 740/0004

      I test at HANA express edition(SAP_BASIS 754/0002) which is working. So maybe my component version (740/0004) is too low? 

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

      Dear Jigang,

      I would say that it's not a problem of compatibility with SAP_BASIS 740/0004...

      I have access to a system with SAP_BASIS 731/0022 and the procedure works fine.

      Are you testing in (SAP_BASIS 740/0004) the case described in my post? I mean break point in EKKO and EKPO tables? If you do not have Purchase Orders in your system could be the reason.

      Just test with TCode SE11:

      1. Take any table, for example T005.
      2. Start debug (/h)
      3. Set break point with filter for table TADIR.

      ... and see if it works and stops for all SELECT for TADIR table.

       

      I hope this helps.

      Regards,

      Alfonso.

      Author's profile photo Jigang Zhang 张吉刚
      Jigang Zhang 张吉刚

      Alfonso Rodríguez Pérez

      Good day. Thanks for your update.

      I did the same testing as your described and PO does exist. If I put only the select statement as a break-point, it will stop at every select. But it'll display PO directly if I put any table like EKKO at the defined filter for RSTPDA_SCRIPT_BP_SQL_DBTAB. And the result is the same for both D/Q/P systems. I assume maybe the basis could set some restrictions for this or it's not default enabled which requires extra parameter setting. Thanks for your time.

      Regards.

      Author's profile photo Kevin Klues genannt Holtkamp
      Kevin Klues genannt Holtkamp

      Is there any way to achieve this for INSERT dtab statements aswell?

       

      When I try to define the filter i get the error message "There are no Filters for this type of breakpoint yet"