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.
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
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! 🙂
Hi Sandra,
Thank you for the test and your feedback.
Regards,
Alfonso.
A very helpful post.
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?
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.
Brilliant post! I found this post very great. Keep updating us.
Very nice post about "filtering" of breakpoints - have not used it yet, but will do so in the future!
Very nice blog, and its really handy too. Thanks for making this blog and saving our time and importantly learning over looked things.
You're a really crack!!
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?
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:
... and see if it works and stops for all SELECT for TADIR table.
I hope this helps.
Regards,
Alfonso.
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.
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"