Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
workbench
Click on the green icon and we can find message class ID: DS, number 017
Then I have to manually filter them one by one to find the correct one. Double click one by one. I ignore all entries with type
MESSAGE E since in my case the message type is not E, but S. After one minute I confirm the following one is the one I try to
find.
Summary: the drawback of A1 is that as you see, if there are many where used list results say a hundred, it still takes you some
time to manually find the correct one.
Create a watch point with below two conditions. After that click F8, the debugger will stop automatically at the correct line you
want. This approach just took me 20 seconds to finish the job.
For detailed screenshot about how to create a watch point in Debugger, see picture provided by Jim Tasker:
How to switch into debugging mode for a modal (pop up) window
Since the command line is not available if there is a modal (pop up window) involved, in this case please refer to SAP Note
118184 about how to switch into debugging mode or refer to this wiki. (http://wiki.scn.sap.com/wiki/display/ABAP/ABAP+TipHow+to+Debug+Pop-up+window)
Or you can use menu via Breakpoints->Breakpoint at->Breakpoint at messages to achieve the same result.
Summary: if the scenario you want to debug is quite complex, for example deep callstack with several components involved,
the debugger might stops at the ABAP code with MESSAGE keyword frequently. You must still manually check whether the
code is just the one you are looking for at each stop. However it is still much more efficient than you debug manually one by
one.
Then use report RS_ABAP_SOURCE_SCAN and maintain the search criteria below. The reason why I do not use program name
RSABAPPROGRAM is that it is just a wrapper report. The actual implementation of SE38 is not put within it.
You can use an alternative Tcode CODE_SCANNER which can achieve the same result:
From my point of view, I do like this A4. I cannot remember how many times it has helped with my debugging life. What's more,
it would be used not only as a debugging tip, but also one way of studying other people's code. Suppose you are curious of how
a certain function is implemented by a software component, it is a good starting point to think of a meaningful search keyword
and specify the package of that software component and go deep into the result code.
Repeat your steps as usual - input an non-exist report and click display button to see the message. After that click back or quit
button in SE38. SAT will automatically be opened to show you all runtime trace information. It will take some time - you can see
the progress information in the bottom:
Click tab "Call Hierarchy", click find button. Input Statement = MESSAGE and go. You will see two search results.
Double click on the hit list row and then you can see the source code.
Summary: if the scenario you are tracing with SAT is complex, you will get a huge trace file. Although you can specify an
extremely big size in trace file, according to my real experience, you will fail to open the result trace file when it exceeds 1 G, at
least in my application server.
We see the logic is that first try to search in DB with inactive version, if failed, try with active version.
So hopefully the code we are trying to find is just in the very neighborhood of the SQL statement in line 774 and 779.
Fortunately in this case, yes it is in line 813.