Q
Problem solve Get help with specific problems with your technologies, process and projects.

Find data underlying a transaction.

I'm trying to find the data underlying a transaction. I put the cursor in the field I want, and press F1. Then...

I click on the button for technical data. This gives me a table and field name. But when I look at the table, it turns out to be a structure.

How can I find where the data is really coming from?


Frequently data is presented in a transaction's screen through a structure. The structure may be populated from a number of sources - and may even contain some calculated fields. In order to find out where the data comes from initially, there are a few techniques which can be used - in no particular order of preference.

The structure may be built up of a number of includes. If the include is in fact a table, then the chances are your data comes from that table.

See if there is a logical database in the business area you are looking at. Looking at the structure of the logical database often reveals the tables used to drive that business area. See if the field name you are looking for is in any of the tables. Logical databases can also be useful in determining how tables are linked together.

Debugging. Start the transaction in debug mode. Set a watchpoint for the structure-field you are interested in. When the debugger breaks, look at the lines just above the breakpoint. This will show where the field was populated. This may be a structure, in which case restart the process using that structure for a watchpoint.

Pretty soon you will get to the table containing the data. Switch SQL trace on, and run your transaction. Switch the trace off, and examine the log. This will detail the tables hit, and the order in which they were hit.. Not all tables hit will be displayed - for example, configuration tables tend not to show up, as they are buffered.

The runtime analyser, SE30, will show all tables accessed by the transaction. There are three courses I've found whose course notes contain diagrams of the tables used for particular sets of data. LO910 (Configuration and Organization in Logistics), LO250 (Configuration of the PP module)and LO630 (Sales Information Systems).

Often, SAP have not been too imaginative in their table naming conventions. For example, most of the information in structure CAUFVD can be found in the view CAUFV. Further, tables ending in KO tend to be header tables, with the underlying data being in a table with the same stem, but ending in PO. E.g. EKKO and EKPO., AFKO and AFPO.

A combination of these techniques should enable you to discover the underlying data.


This was last published in May 2001

Dig Deeper on SAP ABAP

Have a question for an expert?

Please add a title for your question

Get answers from a TechTarget expert on whatever's puzzling you.

You will be able to add details on the next page.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchHRSoftware

Close