10-30-2007 9:36 AM
I am locking one z-table in a module pool.
i have one more FM in which i will have to delete all entries of this table first and then create new entries into the same table.
So I used ENQUEUE_E_TABLE to lock the table while the transaction runs with E mode.
<u><b>issue:</b></u>
on-site cordinator could not create entries in that z-table using FM when the transaction is running. Sounds resonable but when am testing, i could create entries. How is this possible.
Thanks
Kiran
10-30-2007 9:41 AM
Hi,
Do you release the lock or call COMMIT WORK at the end of the LUW?
Regards, Joerg
10-30-2007 9:43 AM
Hi,
Please use Dequeue to release the lock once your work is done.
Thanks,
Sandeep.
10-30-2007 9:45 AM
Hi,
Before updating the table, try to ENQUEUE the table. check for sy-subrc.
if sy-subrc NE 0, then DEQUEUE the table. if sy-subrc eq 0, then update the Ztable.
Regards,
Niyaz
10-30-2007 9:47 AM
Hi Kiran ,
Try like this.
**- Lock the table for updation
CALL FUNCTION 'ENQUEUE_E_TABLEE'
EXPORTING
mode_rstable = 'E'
tabname = 'itab'. ( your table name) EXCEPTIONS
foreign_lock = 1
system_failure = 2
OTHERS = 3.
IF sy-subrc <> 0.
ENDIF.
**- Updating the values in the afterbilled table.
MODIFY itab FROM TABLE i_itab .
COMMIT WORK.
**- Unlock the table after Updation.
CALL FUNCTION 'DEQUEUE_E_TABLEE'
EXPORTING
mode_rstable = 'E'
tabname = ' itab'. ( your table name)
Reward If Useful,
Regards,
Chitra
10-30-2007 9:59 AM
I am exactly doing the same way.
use enque then modify and then de-que
but my issue was different:
on-site team could find the effect of locks but not me.. y?
when i am executing the FM in parallel to the module pool (here lock is set) i can still execute the FM successfully and create the entries successfully.
any clues?
10-30-2007 10:06 AM
Hi,
You can <i>always</i> insert data into a table - even if it is locked. Locking the table using the ENQUEUE_xxx FM is simply a "marker" for the lock - cooperative locking. The lock works like this: You acquire the lock with ENQUEUE. All other processes / users / transactions that try to acquire the lock as well will fail (<b>sy-subrc <> 0</b>).
If you do not check the lock in your FM but rather in the transaction or your module pool, then the UPDATE in the FM will work. The lock is only in SAP memory, <b>not</b> on the database or something like that...
Hope this helps (please reward me if it does).
Regards, Joerg
10-30-2007 10:15 AM
Hi Joerg,
That was quite helpful explanation.
So do you mean that we have to add the lock in the function module also that am executing?
if the lock thru enque fm is only in sap memory, then do i need to create lock objects for that table to handle at DB level?
and the sad part is: when I lock the tabel in the transaction and if another user is trying to create new entries through my 2nd FM, it is still allowing to create and also deleting the old entries as there is a logic to delete all the entries of the table thru this FM.
Plz provide me more in detail on the above 3 points?
Kiran
10-30-2007 10:23 AM
Hi,
In order to fulfil your requirements I would suggest the following:
Move the call to ENQUEUE_TABLE into your FM and add an exception of type, e. g. TABLE_LOCKED to the FM interface.
In your FM call ENQUEUE_TABLE and check sy-subrc. If it is greater than 0 raise the exception TABLE_LOCKED. Otherwise update the table as required.
In your application coding call the FM and check for the exception. Report an error if the exception was raised. After the FM call either call DEQUEUE_TABLE or COMMIT WORK to release the lock. You might also do this in the FM - the decision depends on whether the FM will be called from other programs as well, whether you will later call the FM IN UPDATE TASK etc. Just be shure to release the lock somewehere...
At least that's how I would do it (your mileage may vary
Hope this helps (please reward me if it does).
Regards, Joerg
10-30-2007 11:02 AM
Hi Joerg,
Is it possible to answers for my other 2 queries also.
Many Thanks for your replies
Kiran
10-30-2007 11:10 AM
Hi,
Q1: I am not aware of any possible way to actually physically lock a table at database level from SAP / ABAP. This is simply not the "SAP-style" to do it. SAP recommends and requires the cooperative-locking "style".
Q2: You have to check the table lock <i><b>everywhere</b></i> that you update, modify or delete entries in this table. This way your programming is consistent and the users should get an explanation message if the table is locked. Again, this is <i>your</i> responsibilty as the programmer to check this - SAP and ABAP cannot help you here.
Additionally you might consider creating your own locking object if the locking at database level is too coarse-grained. E. g. there are many locking objects in SAP - usually one for each business object such as sales order. You can create a locking object that works at business object level rather than database table level. That way you can lock individual entries of the table rather than the whole table. Maybe this will help also.
Regards, Joerg