- SAP Managed Tags:
In this blog post, I will be tackling on how we can find the table that a particular transaction reads from. This is particularly useful when dealing with large volumes of data and trying to investigate issues by checking for data record trends or system setups by multiple records at a time. Additionally, table sourcing can also provide us further insight on the connection of a particular business process to a system setup/configuration which might be causing an issue.
Normally, when we are attempting to find the table for a particular object's field we can do so by drilling down the highlighted field via F1->Technical Information (hammer & wrench) buttons. There we will find the table name and the field name of the selected field. This table name we can then plug in the data browser transaction (SE16N) to look on the table records. This allows us to observe for data trends, consistencies, links, and irregularities.
However, depending on the transaction, certain details may be called upon by the back-end programs through structures instead. As a result, we are unable to derive the specific table that holds the piece of information we might be seeking.
As an alternate approach, by using ST05 SQL tracing, we are able to retrieve the tables that have been accessed by a transaction code. From there the field's table we are searching for can be derived.
Below is a summary steps of the process.
We would then be able to see other tables that relate to one another as well. By the same method, we may also see which tables are being accessed by certain reports/transactions which can help if ever we would need to design for custom reports or programs. For more complex reports, however, such as those with calculated fields it would possibly require some functional debugging which is another topic of itself.
Hope this is of some help.
Normally, when we are attempting to find the table for a particular object's field we can do so by drilling down the highlighted field via F1->Technical Information (hammer & wrench) buttons. There we will find the table name and the field name of the selected field. This table name we can then plug in the data browser transaction (SE16N) to look on the table records. This allows us to observe for data trends, consistencies, links, and irregularities.
However, depending on the transaction, certain details may be called upon by the back-end programs through structures instead. As a result, we are unable to derive the specific table that holds the piece of information we might be seeking.
As an alternate approach, by using ST05 SQL tracing, we are able to retrieve the tables that have been accessed by a transaction code. From there the field's table we are searching for can be derived.
Below is a summary steps of the process.
- Activate trace
- Open transaction with the specific information desired
- Deactivate trace
- Display trace
- The Object Name column should provide for the tables that have been accessed by the tcode and in certain cases one may, - Filter the Statement column with "*<object queried (e.g. cost element or PO)>*"
- This is to further isolate the relevant tables specific to the object being queried.
We would then be able to see other tables that relate to one another as well. By the same method, we may also see which tables are being accessed by certain reports/transactions which can help if ever we would need to design for custom reports or programs. For more complex reports, however, such as those with calculated fields it would possibly require some functional debugging which is another topic of itself.
Hope this is of some help.
3 Comments
