Skip to Content

Row level lock using table maintenance views

Hi Guys,


while working with own database tables (Z* tables) the SAP offers us a simple tool to add data or edit these tables. I am talking about the table maintenance views, that you can call via the transaction SM30. The problem is that only one user can edit such a table at once. For my application this was unsatisfying because several users worldwide couldn’t consider waiting until one has finished his changings. I sersched the SCN and found serveral threads handling this issue. After implementing it myself i wanted to share my knowledge with you and carry the information together.

So at first you need the database table and you have to generate a table maintenance view.  While Generating this View choose two step maintenance type, because we want a list where several entries are not editable. In the overview screen no entry is editable in general, in detail screen it gets editable when opened with changing.

When you enter the table maintenance view via SM30 a table level lock is set. This lock has to be removed. The most easiest way to do that is a report that deletes the lock and calls the maintenance view. In detail this is done by reading all system locks. After that we have to delete the relevant lock by calling the function module  ENQUE_DELETE. Now you can call the table maintenance view via the function module   VIEW_MAINTENANCE_CALL.  It is recommendable to add a transaction to this report because it has to be processed to delete the locks. Otherwise if someone opens table maintenance view via SM30 this will not work any more and the lock is set again.

Code Example:

REPORT ztest.


BEGIN OF seltab OCCURS 1.        

        INCLUDE STRUCTURE vimsellist.

DATA: END OF seltab,

BEGIN OF excl_cua_funct OCCURS 1.  

        INCLUDE STRUCTURE vimexclfun.

DATA: END OF excl_cua_funct.

DATA: lt_enq_del       TYPE STANDARD TABLE OF seqg3,

          lt_enq_read      TYPE STANDARD TABLE OF seqg7,

          lw_enq_read     TYPE seqg7,

          lw_enq_del       TYPE seqg3,

          lv_subrc           TYPE sy-subrc.

*Read all locks in system



    gclient = sy-mandt

    gname = ‘ ‘

    guname = ‘*’


    enq = lt_enq_read.

*We will search entry for table level lock for our table

LOOP AT lt_enq_read INTO lw_enq_read WHERE gname EQ ‘RSTABLE’


  MOVE-CORRESPONDING lw_enq_read TO lw_enq_del.

  APPEND lw_enq_del TO lt_enq_del.


*Delete lock entry for our table



    check_upd_requests = 1


    subrc              = lv_subrc


    enq                = lt_enq_del.



    action                               = ‘U’

*   CORR_NUMBER                          = ‘          ‘


*   SHOW_SELECTION_POPUP                 = ‘ ‘

    view_name                            =  ‘Z_OURTABLE’.


Now every entry we are editing has to be locked for other user. To achieve that we need a lock object configured for our table Z_OURTABLE. Everytime we enter the detail screen we check if this entry locked and if so, we set all fields not editable. For that the Screen logic of the dynpro has to be modified. You can add a module that calls the function module created by your locking object. Be careful , if you change your database table, the screens have to be generated new and also the PBO Module has to be added again.

Code example:

MODULE change_locking OUTPUT.



      kunnr = zourtable-kunnr


      foreign_lock   = 1

      system_failure = 2

      OTHERS         = 3.

  IF sy-subrc <> 0.

message ‘Data locked by another user!’ type ‘S’.

* row is locked..


      screen-input = 0.





Everytime a user opens a single record this is locked by the locking object. If any user tries to open the same record all fields are enhanced grey.

I hope this is useful to someone.

kind regards Tobias

You must be Logged on to comment or reply to a post.
    • Everytime a user enters an maintenacne view, these table locks for the affected table are set. If another user enters the same mantenacne dialog, it is not possible for him to open the dialog in editing mode. Therefore we have to delete thes global table locks to be able to enter in editing mode with another user.

      For the first user entering the maintenance dialog this has no effect.

      • OK. Understood now.

        I think that removing the table lock in the maintenance view itself (dequeue by the lock owner) is a better approach. Using direct ENQUE_DELETE isn't recommended.

        I must mention I'm not at peace with the whole concept, though.

        • I dont know at which time the table lock is set. Maybe u can delete it by an event of the maintenacne view, so the code will be related to it.

          why would it be better if the lock owner deletes the lock, i can't see a difference?

          Except of that i don't like the concept to. Even that you can delete table or system locks that easy is a little bit strange.

          • Tobias Steuder wrote:

            why would it be better if the lock owner deletes the lock, i can't see a difference?

            Standard dequeue should be better than external lock intervention...

  • Hi Tobias,

    i understand your motives, since i was following a similar path.

    Nevertheless, un- and relocking the entries seems to be a rather harsh way.

    Probably my aproach would suit your needs as well as it did mine.

    BR - Jörg

    • Hallo Jörg, 😉

      thank you for the recommendation, nice to know that there is an easy an fast solution for using table maintenance views with many users. Nevertheless this wouldn't have worked for my scenario.

      What if a field is set read only and you want to edit it afterwards? Is it possible to add entries to such a table?

      In my case i used and viewcluster with an unique primary key number that was realized by an range number object, this made it necessary to edit the screens anyway and also there were no attributes that could have been grouped rational.