catch lock situations accessing database tables

[rainer_hbenthal]

Hi,

are lock situations (two or more reports are trying to modify the same row) catchable by cx_sy_sql_error? Or by any other technique?

[Former Member]

Are you talking about physical database locks or SAP locks?

Rob

[rainer_hbenthal]

In the case of concurrent updates on a database table i do not want a program failure.

[Former Member]

> In the case of concurrent updates on a database table i do not want a program failure.

If you are talking about SAP locks, then just don't test, but I'm not sure if you can get around physical database locks.

Rob

[rainer_hbenthal]

I need to avoid that an update on a table abends the report due to a deadlock situatiuon. If the update can not be done is not critical.

[Former Member]

Well, according to this, it looks like it might be:

You might try asking this on one of the database forums. (But close this one first.)

Rob

[rainer_hbenthal]

Well, right now, i'm trying to put the data to update the table into the shared memory first, collecting them via a separate report every two hours or so and putting them into the table. Now only one report is writing to that table and i will not have this deadlock situation.

[Former Member]

Hi Rainer,

Well in case of concurrent updates of same table by different programs, you need to use lock objects.

Goto SE11 & create a lock object if its not already available.

2 Funciton modules would be created ENQUEUE_* & DEQUEUE_*

Use it in both the programs. ENQUEUE_* is used to lock the record & DEQUEUE is to unlock the record.

CALL FUNCTION 'ENQUEUE_MARA' 
ExPORTING
MATNR = itab-matnr
...

EXCEPTIONS
...
..
IF sy-subrc <> 0.
message 'Record cannot be locked !' type 'E'.
else.
UPDATE/INSERT TABLE ....


CALL FUNCTION 'DEQUEUE_MARA'
...............


endif.

Pls. ensure that you pass the primary keys to the FM so that locking is done at record level & not at table level !

Best regards,

Prashant