DATABASE UPDATE

COMMIT WORK .. what all does :

1) database update is committed
2) database locks released
3) PERFORM statements with commit (PERFORM ON COMMIT) are
executed
4) UPDATE tasks are done. (CALL FUNCTION IN UPDATE TASK)
5)All open cursors closed.
COMMIT WORK update is asynchronous
COMMIT WORK AND WAIT is how we make it synchronous
LOCAL UPDATES : All modules updates immediately
Locks:
_SCOPE =1.
The dialog program contains the lock that it generates. It is released either
by :
a) Dequeue_<object>
b) Normally at the end of the program.
Programs are ended in the following ways:
(i)
LEAVE PROGRAM
(ii)
LEAVE TO TRANSATION
(iii)
SUBMIT
(iv)
MESSAGE message TYPE A
NOT TO BE USED FOR ASYNCHRONOUS UPDATES .
_SCOPE = 2.
On COMMIT WORK , these locks are not released
On ROLLBACK WORK, these locks are released
_SCOPE =3.

This is a special additional case , done when we require

a) Asynchronous update
b) We want the lock to remain longer than the V1 update
In this lock is shared between dialog program and update program.

ROLLBACK WORK what all does :

1)
2)
3)
4)
5)
6)

All the changes made in the current step is undone.

database locks released
All open cursors closed.
All data in DB LUW is deleted.
The request of FM CALL FUCNTION IN UPDATE TASK is rejected.
The request of FM CALL FUCNTION IN BACKGROUND TASK is
rejected.
7) All the perform subroutines not executed.

BAPI:
It is an interface
Implemented as a method in BOR
BAPI can be used for
1) To map data on the internet or intanet for users who are typically
layman to it, simply for using
2) To cause communication b/w different objects of different business
applications
3) Access data directly
Properties :
1)
2)
3)
4)

Can be called externally as well as internally.

Does not have a presentation layer.
Is object oriented and have access to methods in BOR.
Stable (frozen)interface

5) Released as a function module , data elements in interface

BAPI_TRANSACTION_COMMIT
BAPI_TRANSACTION_ROLLBACK
BAPI implements database changes through UPDATE TASK
CLUSTER TABLE:
Combination of data objects. ( Data objects like internal tables , fields etc )
3 ABAP commands used for these tables :
EXPORT
IMPORT
DELETE
CT are divided in the database in application areas which are recogonizable
in the form of CLUSTER ID.
TABLE FOR CLUSTER DATABASE INDX ( key fields 31 bytes)
Cluster ID default length 22 bytes
SELECT statement to access the key.
Only data from one cluster can be read at a time.
Cross cluster data access , not possible
Cluster table created as transparent table with standardized structure.
If one has to define any data object that is not there in the program , do that
in FROM
Cluster tables are not write protected. That means after one export if we do
it again , it will be overwritten
After IMPORT , return code SY-SUBRC is returned that refers to the
cluster in all rather than a specific business object , if cluster exists , sysubrc = 0 else not.

The structure of the objects imported and exported should correspond , else
run time error .
Name while importing exporting should also be same , else run time error
DELETE deletes the entire cluster , you cannot delete one business object
inside cluster.
On EXPORT , RELID , SRTF2 , CLUSTR , CLUSTD and cluster id
automatically comes
NATIVE SQL
Works both on standard database and decentralized database
Contains statement of DDL and DML of regional database
Error handling and host variable not allowed