on 10-13-2005 3:32 PM
I am trying to use the enqueue_ez_TABLENAME function to lock a record in a table. Does anybody know what all of the input and output parameters do? I can figure out that I send the key of the record to lock, but I am not sure what some of the other export and import parameters mean.
Here is the basis format:
CALL FUNCTION 'ENQUEUE_EZ_TABLE'
EXPORTING
MODE_TABLE = 'E'
MANDT = SY-MANDT
KEY1 = keyvalue1
KEY2 = keyvalue2
X_KEY1 = ' '
X_KEY2 = ' '
_SCOPE = '2'
_WAIT = ' '
_COLLECT = ' '
EXCEPTIONS
FOREIGN_LOCK = 1
SYSTEM_FAILURE = 2
OTHERS = 3.
IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO
WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.
ENDIF.
Does anybody have any code examples where this is working? I tried all of the options from the help text provided, but it still isn't locking the object. I am doing this from an ABAP function called by a BSP page.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Sure, here is an example....
call function 'ENQUEUE_EZHPBDTWRKTMP'
exporting
mode_zhpbdtwrktmp = 'E'
mandt = sy-mandt
cstid = p_cstid
exceptions
foreign_lock = 1
system_failure = 2
others = 3.
if sy-subrc <> 0.
message id sy-msgid type sy-msgty number sy-msgno
with sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4.
endif.
Here CSTID is the key field of the table.
The lock object is an exlusive/cumliative lock. Make sure that this is the case in your lock object.
Also, when setting your locking you can check it out in SM12
Regards,
Rich Heilman
Hi Densie ,
I guess you are setting the lock , but lock gets released when the transaction is over . If after this any other user logs in and tries to set the same lock with same keys he will get a sy-subrc = 0 i.e. he will be able to set lock .
If you really want to see that other user get a Sy-subrc ne 0 then you should put a break point just after the statement of the function call for first user . Let the program control remain here , go and execute the transaction for other user.
Cheers
- When your enqueue call is complete, can you check in SM12 whether the corresponding lock entry is there? (Maybe by stopping in debugger just after the function call)
- What is the scope of the lock? (Default '2' is ok)
- When you say you are testing it with two user-sessions, do you get a sy-subrc = 0 for the second enqueue call? It will only be zero if the enqueue table entry from the first one is not there (verified in first option above).
- If you are using an RFC call, the lock object has to be so defined (check the lock object property).
- If still it is not solved, test the enqueue function in SE37 and see if the lock entry is created in SM12. If it does, you can run it again in the next session to verify that return-code is non-zero (in which case there is something wrong in the application, maybe the call is not made somehow).
hope this helps,
Hi,
check this it may help you...
http://help.sap.com/saphelp_erp2004/helpdata/en/cf/21eea5446011d189700000e8322d00/frameset.htm
reward points for helpfull answers and close the thread if your query is solved.
regards,
venu.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
Check this out -
http://help.sap.com//saphelp_470/helpdata/EN/cf/21eebf446011d189700000e8322d00/content.htm
Cheers.
( Dont forget to reward if answers were helpful )
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'm using this to lock a record for update, and prevent anybody else from getting the record. I am logging in as 2 separate users, and locking the record on the 1st user. I am expecting to see a sy-subrc value other than 0 for the 2nd user, but I am always getting zero. I'm trying to figure out why it isn't returning an error when the 2nd user tries to access the same record.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I found the following documentation...
<i>
Activating a lock object in the ABAP Dictionary automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks.
The generated function modules are automatically assigned to function groups. You should not change these function modules and their assignment to function groups since the function modules are generated again each time the lock object is activated.
Never transport the function groups, which contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. Always transport the lock objects. When a lock object is activated in the target system, the function modules are generated again and correctly assigned to function groups.
Parameters of the Function Modules
Field Names of the Lock Object
The keys to be locked must be passed here.
A further parameter X_<field> that defines the lock behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned the initial value and X_<field> is defined as X, the lock is set with exactly the initial value of <field>.
Parameters for Passing Locks to the Update Program
A lock is generally removed at the end of the transaction or when the corresponding DEQUEUE function module is called. However, this is not the case if the transaction has called update routines. In this case a parameter must check that the lock has been removed.
Parameter _SCOPE controls how the lock or lock release is passed to the update program (see The Owner Concept for Locks). You have the following options:
_SCOPE = 1: Locks and lock releases are not passed to the update program. The lock is removed when the transaction is ended.
_SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.
_SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program. This is the standard setting for the DEQUEUE function module.
Parameters for Lock Mode
A parameter MODE_<TAB> exists for each base table TAB of the lock object. The lock mode for this base table can be set dynamically with this parameter. Valid values for this parameter are S (shared), E (exclusive) and X (exclusive but not cumulative).
The lock mode specified when the lock object for the table is created is the default value for this parameter. This default value can however be overridden as required when the function module is called.
If a lock set with a lock mode is to be removed by calling the DEQUEUE function module, this call must have the same value for the parameter MODE_<TAB>.
Controlling Lock Transmission
Parameter _COLLECT controls whether the lock request or lock release should be performed directly or whether it should first be written to the local lock container. This parameter can have the following values:
Initial value: The lock request or lock release is sent directly to the lock server.
X : The lock request or lock release is placed in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.
Behavior for Lock Conflicts (ENQUEUE only)
The ENQUEUE function module also has the parameter _WAIT. This parameter determines the lock behavior when there is a lock conflict.
You have the following options:
Initial value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered.
X : If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.
Controlling Deletion of the Lock Entry (DEQUEUE only)
The DEQUEUE function module also has the parameter _SYNCHRON.
If X is passed, the DEQUEUE function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the lock is removed, the entry in the lock table may still exist.
Exceptions of the ENQUEUE Function Module
FOREIGN_LOCK: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1.
SYSTEM_FAILURE: This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set.
If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.
Reference Fields for RFC-Enabled Lock Objects
The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module therefore have the following reference fields for RFC-enabled lock objects:
Parameters
Reference fields
X_<field name>
DDENQ_LIKE-XPARFLAG
_WAIT
DDENQ_LIKE-WAITFLAG
_SCOPE
DDENQ_LIKE-SCOPE
_SYNCHRON
DDENQ_LIKE-SYNCHRON
</i>
Please award points according and mark this post as solved if your question has been answered. Thanks.
Regards,
Rich Heilman
_WAIT parameter set to "X" means that the system will wait a certain time for the lock to be released before it will give you an error that the record is locked. The time is a system value.
The rest, I've never used.
Regards,
Rich Heilman
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
There are stars next to each reply to your post. Award points to all answers which have helped you. 2 points for helpful, 6 for very helpful, or 10 for solved problem. The act of awarding 10 points to someone will "closed" the post. If you solved it on your own, then you mark it as so, and then 10 points are not awarded. Welcome to SDN!!!
Regards,
Rich Heilman
User | Count |
---|---|
2 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.