This article describes how locking hangs together, in a nutshell of course... One of the main components of an R/3 system is the lock server. There is no need to understand how it works, but the purpose should be clear: it allows developments to "place a lock" from anywhere in the system. No matter how many users, no matter how many application servers, no matter which application server the lock is placed from. Locks will be system wide and placing the lock can either succeed or fail, which is what ABAP development should respond to (e.g. by stopping).
Create lock objects
Use transaction SE11 to create (or change) your lock object. But before doing so:
Make sure you know all there is to know about locking
Implementing a lock object there are two main questions: how and why.. It all comes down to a few rules that need to be adhered to.
Question If you are setting up your own transaction with header and item data, you should use locking. But do you really need to lock both the header and all the items ?
Question If you want to change any line item table from standard SAP by directly updating it (dare-devil...), do you lock it using a new lock (read: lock object) ?
The following principles apply for you as well as the developers at SAP:
- When a maintenance transaction is created, one can be sure that no-one else is using the tables you are creating.
- Thus you can also be sure that your transaction will always be used to maintain these tables. If not, someone is breaking the rules.
- So basically it's all up to you: if you do not allow any changes to the line item table, unless the header table is locked, you are automatically (or rather functionally) locking all line items as well
Bottom line: make sure your transaction does not allow changes to line items if the header cannot be locked. The same way SAP does it. You could try that by simply going into the transaction for "Change Sales document" and open a line-item. By checking the lock objects that are reserved for you (R/3 => Tools => Administration => Monitoring =>) Lock entries or transaction SM12. Only table VBAK will be locked (the header). Try the same for the function "Change accounting document", again only the header table will be locked.
Not only will this way of working save a lot of senseless locking, it will also be the way SAP does it, which is to my opinion the best programming standard to use.
One step further: the second question about locking entries in the table you want to change are actually very wrong. By doing that, you would not be acting "according to an acceptable quality", and actually generate dumps on the standard SAP programming. What you should do is find out what locking is being done on the data you want to alter, and actually do the same locking. Only this way you can be sure that there are no locking errors. Mind you, you still have to be extremely careful when changing standard SAP tables directly: how can you be absolutely sure you are doing it the way SAP would do it ? Aren't there any other tables which would need to be updated as well ?? My advise: try using BAPIs first, or if they are not available, a good old Batch Input could do the trick as well.
So how can you find out what lock objects a program is using ? Very simple, several ways possible: first check out the Lock entries overview as in the example above. Or maybe search the source of the program for CALL FUNCTION ENQUEUE_, which should list all lockings a transaction does. And of course, you could list all available lock objects in the data dictionary, there's only 500 or so for the whole R/3 system (when I looked in version 3.1h). Selecting on a description should narrow down your possibilities to useful figures.