Contents (open link with ctrl + click)

1. SAP Table Maintenance Generator

2. ABAP performance standards

3. Run-time analysis in SAP ABAP

1. SAP Table Maintenance Generator

SAP Table Maintenance Generator (TMG) is a tool to generate a table maintenance program i.e. it will
generate a program to maintain (Create, Edit & Delete) entries in a table.

To generate a table maintenance generator (TMG) for a table, display the table in ABAP dictionary (SE11)

Select “Display/Maintenance Allowed” for Data Browser/Table View maintenance under Delivery
Maintenance tab.

Go to Menu Utilities –> Table Maintenance Generator

Enter the proper authorization group (&NC& is without any authorization) and function group. If the
entered function group does not exist, it will create a new function group to store the dialog modules of
TMG. Select “one step” for Maintenance type and click on “Find Screen Numbers” on application toolbar

Select Propose screen numbers and click on continue

The screen number for overview screen will be automatically populated. Now click on CREATE icon on
application toolbar

Assign TMG and function group to proper package and save

Table maintenance program is created with the above message in the status bar. Now to maintain entries
in the table, go to Maintain Table Views (SM30)

In SM30 enter table name and click on maintain

Click on New Entries button on application toolbar to maintain new entries in the table
SAP Table Maintenance Generator (TMG) is a tool, used to create a table maintenance program,
which can be customized, to be used by the end users to maintain the table for example, user can create
a new entry in the table, can change the existing data, and can delete the data

SAP Table Maintenance Generator

SAP Table Maintenance Generator (TMG) is a tool, used to create a table maintenance program, which
can be customized, to be used by the end users to maintain the table for example, user can create a new
entry in the table, can change the existing data, and can delete the data.

To create Table Maintenance Generator (TMG) you can go to SE11 t-code and then enter the table name
and then click on change button. Go to Utilities --- Table Maintenance Generator.

Alternatively, you can access directly by using transaction code - SE54.

Why we need to use Table Maintenance Generator?

In production systems, the end-users generally won't be having access to SE11 or SE16 transaction code.
So, if they need to maintain this table they need an alternate way to do so.

The benefit of Table Maintenance Generator is that the restriction can be put on each field column and
also gives end-users to change or modify multiple entries at the same time. The table maintenance events
allows to change the generated table maintenance at specified position.

You can go to menu "Environment --- Modification" where there is an option for Screen Maintenance, User
Interface, Events, and Source Code. Using an events for example - you an put additional restrictions and
warnings, or you can display message before SAVE, DELETE or CHANGE. There are several pre-define
standard events available by SAP which you can use to enhance the functionality of your generated table
maintenance program.

2. ABAP performance standards

 Run Extended syntax checks with character literals checkbox switched on & Code Inspector to rectify all relevant
errors and warning (e.g. Use the results of the above checks to remove all variables/constants etc that are
declared but are not used)

 Transaction SE30 (ABAP Runtime Analysis) must be checked to measure/compare program

performance/runtime if program has multiple inefficient databases selects or complicated internal table
operations

 Use transaction ST05 (SQL Trace) to see what indices your database accesses are using. Check these indices
against your “where” clause to assure they are significant. Check other indices for this table and where you have
to change your “where” clause to use it. Create new indices if necessary, but do not forget to check the impact
by consulting onsite coordinator TYPE (data element) command is used while declaring the fields whenever
feasible instead of LIKE. Remember not always the data element name matches with the table field name
Internal Table is defined with “TYPE STANDARD TABLE OF” & Work-Areas is used instead of header lines

 Global variables are minimized by declaring local variables or by passing variables through parameters &
arguments while creating internal subroutine(s)

 In SELECT statement, only the required fields are selected in the same order as they reside on the database
table/structure/view
 For selecting single row from a database table, “SELECT UP to 1 Rows” is used. “Select Single” is used only
when full primary key combination is known

 No SELECT * is used

 Use “SELECT INTO TABLE” rather than “SELECT INTO CORRESPONDING FIELDS OF TABLE”

 Always specify as many primary keys as possible in WHERE clause to make the Select efficient

 Always select into an internal table, except when the table will be very large (i.e., when the internal table will be
greater than 500,000 records). Use “Up to N Rows” when the number of records needed is known

 Select statement within a GET event is not used

 Wild cards like „A%‟ is avoided as much as possible

 Nested Select is not used instead “Inner Join” and/or “For all Entries” is used. “For all Entries” is to be used over
“Loop at ITAB / Select / ENDLOOP” (FOR ALL ENTRIES retrieves a unique result set so ensure you retrieve the
full key from the database)
 When creating joins over database tables there should be an index at least on the inner table for the fields in the
join condition else use “ FOR ALL ENTRIES” select statement

 Usage of JOIN is limited to a maximum of 2 i.e. not more than 3 database tables are joined at one time

 CHECK that the internal table used in FOR ALL ENTRIES is NOT empty as this will retrieve all entries from the
table

 Delete adjacent duplicate entries from internal table before selection from database table using “ FOR ALL
ENTRIES” statement

 For copying internal tables use „=‟ operator instead of Looping & Appending

 SORT inside a LOOP is not used

 Sort internal table by fields in the correct order, which are used in a READ TABLE statement using BINARY
SEARCH. If the order of sorting is invalid the BINARY SEARCH will never work

 For large internal tables where only some rows are to be processed, use SORT and then the READ TABLE
command is used to set index to first relevant row before looping from that index. Use CHECK or
IF…EXIT…ENDIF as appropriate to exit from the loop

 Sort fields and Sort Order on the SORT statement should be mentioned explicitly (e.g. SORT ITAB BY FLD1
FLD2 ASCENDING)

 Hashed table is used for processing large amount of data (provided that you access single records only, and all
with a fully specified key)

 DELETE or SORT is not used on a hashed table since it increases memory consumption

 Sorted table is used for range accesses involving table key or index accesses

 Fields specified in the WHERE condition with the critical operators NOT and <> (negative SQL statements)
cannot be used for a search using database indexes. Whenever possible formulate SQL statements positively

 When coding IF or CASE, testing conditions are nested so that the most frequently true conditions are processed
first. Also CASE is used instead of IF when testing multiple fields “equal to” something

 LOOP AT ITAB INTO WORKAREA WHERE K = „XXX‟ should be used instead of LOOP AT ITAB INTO
WORKAREA / CHECK ITAB-K = „XXX‟

 Also READ TABLE INTO WORKAREA should be used instead of only READ TABLE
 After the APPEND statement inside a loop, the work area that has been appended is cleared

 Internal tables, Work areas & Global Variables are freed when no longer needed (e.g. using the FREE /
REFRESH command), especially when the tables are large or the program is a batch program

 Do not delete the records of internal table inside the Loop – End loop.
Do not use: LOOP AT ITAB WHERE EQUNR = „00001011‟.
DELETE ITAB.
ENDLOOP
.
Use: DELETE ITAB WHERE EQUNR = „00001011‟.

 Use the MODIFY ITAB ... TRANSPORTING f1 f2 ... for single line, and MODIFY ITAB ... TRANSPORTING f1 f2
... WHERE condition for a set of line, to accelerate the updating of internal table

 If possible, Update/Insert statement is used instead of Modify

 Is the following steps ensured during database updates?

 Lock data to be edited
 Read current data from the database
 Process data and write it to the database

 Release the locks set at the beginning

 Try to avoid logical databases. If your program uses a logical database, but does not require all fields belonging
to a certain GET event, always use the FIELDS addition to reduce the amount of data selected by the logical
database

 Avoid the aggregate (Count, Max, Min) functions in the database selection

 Use Parallel Cursor methods for nested loop into the internal tables if second internal table contains
considerable number of records

 In Smartform / Sapscript do not make redundant data retrieval where data is available in interface

3. Run-time analysis in SAP ABAP

Check efficiency of SAP ABAP programs and Function modules using SAP
run-time analysis

 Run-time analysis is used to check the efficiency of a program or function module or t-

code in terms of what is the load on the database server, application server, presentation
server etc.
 The run-time analysis will display the load in a graph with %'s and the time in micro
seconds.
 The graph will be displayed with either red color or green color.
 If the graph contains green color, then the program execution time is very good or very
less.
 If the graph contains red color, the program execution time is very bad or very long .
 Always make sure the the load on database server should be less than 40% and should
be green.

T-code for run-time analysis is SE30 or SAT (Latest Versions)

Example program on run time analysis in SAP ABAP
Program1: Create a program to get MARA details and display as below

Go to SE30, provide program name - ZMARA_REPORT,

click on execute button, the out put will be displayed, click on back and click on evaluate to see run-time
analysis

The result will be like below(may vary based on server capacity)

You can see the database layer is in green color means the standards are good. A good program
with coding standards always have database layers is in green color