Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

Debugging tools

Former Member
0 Kudos

Hi ALl,

what are the various debugging tools? what is performance analysis,lock objects & rollback?

Points will be awarded


Former Member
0 Kudos

Former Member
0 Kudos


Chek these links:

1. Performance Analysis Tools

2. SE30 - RunTime Analysis

3. ST05 - Sql Trace

Hope they help you



Former Member
0 Kudos


Have a look at the following links..

<a href="">Debugger</a>

<a href="">Perfomance analysis</a>

<a href="">lock objects</a>

hope the links are useful...



Active Contributor
0 Kudos

Open SQL contains the statements

<b>COMMIT WORK and ROLLBACK WORK.</b>for confirming or undoing database updates. COMMIT WORK always concludes a database Logical Unit of Work and starts a new one. ROLLBACK WORK always undoes all changes back to the start of the database Logical Unit of Work .


lock objects</b>

The SAP lock concept is based on lock objects. Lock objects allow you to set an SAP lock for an entire application object. An application object consists of one or more entries in a database table, or entries from more than one database table that are linked using foreign key relationships.

Before you can set an SAP lock in an ABAP program, you must first create a lock object in the ABAP Dictionary. A lock object definition contains the database tables and their key fields on the basis of which you want to set a lock. When you create a lock object, the system automatically generates two function modules with the names ENQUEUE_<lock object name> and DEQUEUE_<lock object name> . You can then set and release SAP locks in your ABAP program by calling these function modules in a CALL FUNCTION statement.

Unlike the database, which sets physical locks, the SAP lock mechanism sets logical locks. This means that

A locked database entry is not physically locked in the database table.

The lock entry is merely entered as a lock argument in the central R/3 lock table. The lock argument is made up of the primary key field values for the tables in the lock object. These are import parameters of the enqueue function module. The lock is independent of database LUWs. It is released either implicitly when the database update or the SAP transaction ends, or explicitly, using the corresponding dequeue function module. You can use a special parameter in the update function module to set the exact point at which the lock is released during the database update.

A locked entry does not necessarily have to exist in a database table.

You can, for example, set a lock as a precaution for a database entry that is not written to the database until the update at the end of the SAP LUW.

The effectiveness of the locks depends on cooperative application programming.

Since there are no physical locks in the database tables themselves, all programs that use the same application objects must look in the central table themselves for any locks. There is no mechanism that automatically prevents a program from ignoring the locks in the lock table.

Lock Types

There are two types of lock in the R/3 System:

Shared lock

Shared locks (or read locks) allow you to prevent data from being changed while you are reading it. They prevent other programs from setting an exclusive lock (write lock) to change the object. It does not, however, prevent other programs from setting further read locks.

Exclusive lock

Exclusive locks (or write locks) allow you to prevent data from being changed while you are changing it yourself. An exclusive lock, as its name suggests, locks an application object for exclusive use by the program that sets it. No other program can then set either a shared lock or an exclusive lock for the same application object.

<b>performance analysis</b>

The performance of an ABAP program is largely determined by the efficiency of its database accesses. It is therefore worth analyzing your SQL statements closely. To help you to do this, you should use the Performance Trace and Runtime Analysis tools (Test menu in the ABAP Workbench). In particular, the SQL Trace in the Performance Trace shows you which parts of Open SQL statements are processed where, and how long they take.

To understand how SQL statements affect the runtime of ABAP programs, you need to understand the underlying system architecture. The work processes of an application server are logged onto the database system (server) as users (clients) for as long as the R/3 System is running. The database management system (DBMS) forms the connection between users and data.



Former Member
0 Kudos


Performance Analysis->Need for performance tuning

In this world of SAP programming, ABAP is the universal language. In most of the projects, the focus is on getting a team of ABAP programmers as soon as possible, handing over the technical specifications to them and asking them to churn out the ABAP programs within the “given deadlines”.

Often due to this pressure of schedules and deliveries, the main focus of making a efficient program takes a back seat. An efficient ABAP program is one which delivers the required output to the user in a finite time as per the complexity of the program, rather than hearing the comment “I put the program to run, have my lunch and come back to check the results”.

Leaving aside the hyperbole, a performance optimized ABAP program saves the time of the end user, thus increasing the productivity of the user, and in turn keeping the user and the management happy.

Lock Objects->The R/3 System synchronizes simultaneous access of several users to the same data records with a lock mechanism. When interactive transactions are programmed, locks are set and released by calling function modules (see Function Modules for Lock Requests). These function modules are automatically generated from the definition of lock objects in the ABAP Dictionary.

RollBack->In a ROLLBACK, all the changes made by a transaction or a subtransaction on the database instance are reversed.

· Changes closed with a COMMIT can no longer be reversed with a ROLLBACK.

· As a result of a ROLLBACK, a new transaction is implicitly opened.

In normal database operation, the database system performs the required ROLLBACK actions independently. However, ROLLBACK can also be explicitly requested using appropriate SQL statements.

I hope this will help you to solve your problem


Mrutyunjaya Tripathy