commit after locking database ?????

[Former Member]

Hi Experts.,

Is it necessary to commit work though i am holding a lock on a database ??

reasons and example needed............

<REMOVED BY MODERATOR>

Edited by: Alvaro Tejada Galindo on Jun 12, 2008 2:19 PM

[Former Member]

Just holding a lock on table does not commit. It'll prevent

others from accessing only . U need to commit even if UR

holding a lock ..

[Former Member]

hii

COMMIT WORK is for updation checking.If data updated successfully then commit work should be done means it should save that changes or else rollback will done.

For every updation lock will be there for database.so though lock is there commitwork will be used.its not realted with each other.locking is only to prevent other for accessing same data & updating it.

<REMOVED BY MODERATOR>

thx

twinkal

Edited by: twinkal patel on Jun 12, 2008 1:56 PM

Edited by: Alvaro Tejada Galindo on Jun 12, 2008 4:06 PM

[Former Member]

Hi,

Yes, it is necessary to commit the work explicitly.Locking doesnt commit the data to the database.

Regards

[Former Member]

Hi,

The database system uses locks to ensure that two or more users cannot change the same data simultaneously, since this could lead to inconsistent data being written to the database. A database lock can only be active for the duration of a database LUW. They are automatically released when the database LUW ends. In order to program SAP LUWs, we need

a lock mechanism within the R/3 System that allows us to create locks with a longer lifetime.

The Open SQL statements INSERT, UPDATE, MODIFY, and DELETE allow you to program database changes.

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.

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.

Example :

The user requests a given flight i.e (on screen 100) display or update it (on screen 200). If the user chooses Change, the table entry is locked; if he or she chooses Display, it is not.

The PAI processing for screen 100 in this transaction processes the user input and prepares for the requested action (Change or Display). If the user chooses Change, the program locks the relevant database object by calling the corresponding ENQUEUE function.

MODULE USER_COMMAND_0100 INPUT.

CASE OK_CODE.

WHEN 'SHOW'....

WHEN 'CHNG'.

• <...Authority-check and other code...>

CALL FUNCTION 'ENQUEUE_ESFLIGHT'

EXPORTING

MANDT = SY-MANDT

CARRID = SPFLI-CARRID

CONNID = SPFLI-CONNID

EXCEPTIONS

FOREIGN_LOCK = 1

SYSTEM_FAILURE = 2

OTHERS = 3.

IF SY-SUBRC NE 0.

MESSAGE ID SY-MSGID

TYPE 'E'

NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

.....

At the end of a transaction, the locks are released automatically. However, there are exceptions if you have called update routines within the transaction. You can release a lock explicitly by calling the corresponding DEQUEUE module. As the programmer, you must decide for yourself the point at which it makes most sense to release the locks (for example, to make the data available to other transactions).

The subroutine UNLOCK_FLIGHT calls the DEQUEUE function module for the lock object ESFLIGHT:

FORM UNLOCK_FLIGHT.

CALL FUNCTION 'DEQUEUE_ESFLIGHT'

EXPORTING

MANDT = SY-MANDT

CARRID = SPFLI-CARRID

CONNID = SPFLI-CONNID

EXCEPTIONS

OTHERS = 1.

SET SCREEN 100.

ENDFORM.

You might use this for the BACK and EXIT functions in a PAI module for screen 200 in this example transaction. In the program, the system checks whether the user leaves the screen without having saved his or her changes. If so, the PROMPT_AND_SAVE routine sends a reminder, and gives the user the opportunity to save the changes. The flight can be unlocked by calling the UNLOCK_FLIGHT subroutine.

MODULE USER_COMMAND_0200 INPUT.

CASE OK_CODE.

WHEN 'SAVE'....

WHEN 'EXIT'.

CLEAR OK_CODE.

IF OLD_SPFLI NE SPFLI.

PERFORM PROMPT_AND_SAVE.

ENDIF.

PERFORM UNLOCK_FLIGHT.

LEAVE TO SCREEN 0.

WHEN 'BACK'....

I hope with this example you get a clear picture of lock concept.

<REMOVED BY MODERATOR>

Thanks.

Dhanashri.

Edited by: Alvaro Tejada Galindo on Jun 12, 2008 2:19 PM

[Former Member]

Just think a report that locks a certain row of a table, than performs an update and after 10.000 of those operations does a COMMIT WORK to save a bulk of changes to the database and then works on the next 10.000 items and so. If we don't use update modules for database changes the lock objects still exists and will vanish not until end of the report . This is the case why the people use the commit work.