LOCK OBJECT

[Former Member]

Hi Everyone,

I believe I am missing something in the concept of Lock object.

Does SAP not take care of locking when multiple users are trying to access the same data?

Why do we have to explicitly create a lock object and use it in our programs?

I would greatly appreciate any answers..

Thanks

[Former Member]

You do the locking and unlocking with the enqueue/dequeue functions. But these are logical locks, not physical. Any program that accesses the locked tables must check these locks themselves. There is nothing to prevent multiple programs from updating locked data.

Rob

[Former Member]

And how do we know which tables are the ones to be checked for locks? For ex: If I want to change some values in a custom table by direct update do i have to first call the FM ENQUE_E....etc., and check.

and what (theoretically) if i want to do a direct update on VBAK from a prgram? would i be doing the same thing?

thanks

[former_member221770]

Hi Srinivas,

Transaction SM12 can be used to see which tables are locked at any one time. If you are doing a direct update to VBAK (and I know you wouldn't right!) then yes, you should check to see if the record you are updating is locked or not. Inthis case you woule use FM 'ENQUEUE_EVVBAKE' to make sure that someone is not currently editing the sales document. I believe all the standard SAP transactions employ this locking mechanism.

The way I perform these checks would be something as follows:

• Perform the check up to 100 times

do 100 times.

• See if you can lock the record

call function 'ENQUEUE_XXXX'.

if sy-subrc eq 0.

• You can lock the record, now unlock it, perform your

• update and exit the DO loop

call function 'DEQUEUE_XXXX'.

update XXXX.

commit work.

exit.

else.

• Record is locked, wait 1 second and try again

wait up to 1 seconds.

endif.

enddo.

Hope you find this useful.

Cheers,

Pat.

PS. Kindly award Reward Points to the suggestions that you find useful.

[Former Member]

Hi Srinivas

This is a really good question.

SAP uses logical locking for a few reasons.

One is client server architecture.

Client server architecture means that you have one DB server with potentially thousands of users on several application servers.

To maximise dialog performance, you read the data from the DB, perform the user dialog, then save the data to the DB in one go (in the background - the so-called <i>Update Task</i>) while the user gets on with the next transaction. The transaction is either in the DB completely or not at all. No middle ground.

During this time, you can't lock the tables (and there could be many) at a physical level. That would cause too much contention.

So, you build your locks at an application level. You place a logical lock at the business object level. Not on every table - just on the unique ID of the business object. You release the lock (automatically done for you) after the Update Task.

The important bit it that the locks are at application level, which means that it is kind of an 'honor' system - <b>all applications accessing that object for change purposes MUST respect the locking convention</b>.

Nothing is stopping you from NOT doing this, apart from your desire for high quality software and data integrity.

Now, SAP R/3 + ERP + etc software is <i>application software</i> - not just a big DB - and you should <b>never update an SAP table directly</b>. Not even if you have locked it.

Like all rules, there are exceptional circumstances, of course.

However, if you directly update a table, you are not generating change documents (audit logs), you are not generating change pointers for system integration, you are not respecting application logic. You are also potentially corrupting the DB and preventing the customer from receiving the full value of SAP Support.

If you are going to directly update an SAP table, make sure you do so with full knowledge of what you are doing.

</rant>

Cheers

Dom

[Former Member]

Hi Srini,

If you were updating just one table, then the locking is taken care of by the DB. SAP doenst really have to worry about it.

But when u save a Sales order for example, it is not one table. it is a set of related tables. like vbak, vbap, vbuk for example. Now, I need to have consistency between the tables, and hence whenever i am changing something for a S.O., i have to lock all the tables for a S.O. (vbak, vbap, vbuk, etc) so that no body else changes any of these tables.

And u shd also remember the transaction concept. it is do all or nothing => commit all or reverse all. For this reason too, u need to think of this whole S.O. as one unit of work, what we call in SAP as a Logical unit of work LUW.

Hope this is clear.

PS: Remember 2 reward points.

Reg,

PP.

[jayanthi_jayaraman]

Hi,

Check this link.

http://help.sap.com/saphelp_40b/helpdata/en/cf/21eea5446011d189700000e8322d00/content.htm

Kindly reward points by clicking the star on the left of the reply if it is useful.