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).
What you should do and not do where locking is concerned...
- Do Use the locking mechanism when changing table records (change = create, update and/or delete)
- Don't Create a new lock object or use an alternative one if one is already set up for the logical unit of work you want to address.
Locking is in place for many objects or documents in the system. They can be viewed and where necessary even be removed.
In a live system removing a lock should not be a daily business matter, but it is good to know the tooling to view and remove locks is available. With transaction SM12 the locks that are in place are listed. Valuable information for a developer. If you need to know how some standard functionality locks it's business, so you can apply the same locks, ensuring a collision with sap functionality is not possible.
Are you locking yourself? Did you get thrown out of the system but locks are still in place? Is someone locking the customizing table you need to work on - and he's in a meeting? Good thing SM12 lets you remove lock entries. If you have the authorization of course.
In most cases the process that checks a lock will need to place the lock as well. In most cases... What if you need to know whether something is locked without actually locking it ? E.g. you would like to update a table which acts like a process list of task list for another program. You may need to know whether this "other" program is currently running to process entries, to which you would like to respond by putting your entries in the process list with the "delayed" flag (key field) on. Here's an example lock with a read for this lock: (lock object E_EPROG).
As soon as a transparent table record has to be created or modified (or removed), you have to consider the fact that R/3 is a multi-user system.Thus before changing any data we must claim it for the changes. The SAP R/3 Lock-server reserves and releases data for all using processes. A Lock-object has to be created to claim records from a table. See "Data dictionary maintenance", SAP menu => Tools => ABAP Workbench => Development SE11), select radio-button "Lock object". When creating a Lock-object SAP creates two function building blocks: ENQUEUE_NNNN and DEQUEUE_NNNN, (NNNN is the name of the created Lock-object). The ABAP can call ENQUEUE_NNNN to lock the object and DEQUEUE_NNNN to release it again.
When you design a data model, it's more than likely you will need a unique number for your key fields. Whenever a new number is required, you could select on your own table and find the largest number, add 1 to that and your new key field value is ready. SAP caters for a bit more powerful and quicker "number ranging" than that. A number range is DDIC object that holds information on what new number to pick next. It can hold several "ranges" for your key field (e.g. related to a document type).
The number range settings should be regarded as a system-wide overall setting, which applies to a variety of objects on the system. These objects or documents are standard SAP objects, however customer number ranges are very common as well. Here's a transaction code overview for relevant Number Range related transactions:
SM56- Number Range Buffer (administrator type stuff, resetting buffers)SNUM- Number Range Object Maintenance (object name should be supplied)
The internal number range is a beautiful concept, but if the actual documents on your system are in an internal range (typically because of a migration) the system will eventually cause collisions Here is an example of a function module that works like a protection shell around the NUMBER_GET_NEXT. All it does is check an actual database table for the existance of the "next number" - as R/3 does not do this. R/3 assumes (correclty) that an internal number range will never be used for external numbering. The example will repeat "pulling a new number" until the result is an actual new number.