SAP IP Locking Issue

[Former Member]

Hello,

I have a problem in undertanding the locking logic in SAP IP.

I have two planning querys working on the same aggregation level. The only difference of the two queries are the selection variables.

For query a it is 0Employee and for b 0Costcenter.

If I start a twice with different employees it works.

But when I start a with a employee and b with a costcenter (a costcenter different from the emplopyee), I get an error that the records are locked by the user which executes query a.

I would understand this issue if query b is called with the costcenter of the respective employee. The there would be a conflict in locking the same records. but in the case the employee is different from the costcenter.

Can anyone explain this issue to me?

Thanks!

[Former Member]

Hi Gregor,

thanks for your help.

Okay, I thought the locks are record based. Then it is clear to me. I didnt found this information in any documentation.

Do you have any idea to bypass this problem?

Regards

Michael

[cornelia_lezoch]

Hi Michael,

you do not need a bypass. you need to set the correct combination of lock characteristics in RSPLSE as Gregor already told you.

read a bit here:

Lock Concept and Lock Management - Planning Business Data with BW Integrated Planning - SAP Library

you need to define what selections the users should be able to work on in parallel.

Then use those char as the locking char

i.e. if users shall be able to work on the data for employees in parallel, the employee is lock relevant and user MUST do a selection on the eployees (or the users locks all employees).

regards

Cornelia

[gregor_dieckmann]

Hi Michael,

if the two characteristics 0EMPLOYEE and 0COSTCENTER are lock relevant the the 2 dimensional data reqion described by the static filter of the query is locked. So overlapping data reqions will lead to a lock conflict.

You say 0EMPLOYEE and 0COSTCENTER are somehow related. What exactly is the relation? Lock relevant characteristics are considered as independent. If 0EMPLOYEE has 0COSTCENTER as an attribute you might consider to make it a navigation attribute 0EMPLOYEE__0COSTCENTER and to make the navigation attribute lock relevant. Then it might be possible to define the filter in the query in such a way that the locked data regions are not overlapping.

Lock relevant characteristics are defined in RSPLSE; you can make navigation attributes lock relevant in the 'expert mode'; you find all details in the sizing note 928044.

Regards,

Gregor

[Former Member]

Hi Gregor

The target of the application is to plan working hours for employees.

The aggregation level contrains 0employee 0costcenter and the customer.

In query a an employee plans his avaiable hours. There is only a filter on employee and he must plan for a costcenter an a customer.

In query b a costcenter is planned. There is only a filter for costcenter and employee and customer is planned.

There can be overlapping planning records. If I choose in query a an employee which belongs to a costcenter which is used in query b.

Employee has a attribute costcenter. But this is only its "normal" costcenter. But he can also plan his ours for other costcenters.

Regards

Michael

[gregor_dieckmann]

Hi Michael,

so in fact you have three characteristics, and as I said above the locks are based on the data region described by the static filter of the query. The locks are not record based.

So if the data regions descibed by the filter of query A and B have an overlap one will get a lock conflict. This is the feature.

The documentation contains information about the lock concept. In transaction RSPLSE you can see the last lock conflict and check the selections.

Regards,

Gregor

[Former Member]

Hi Gregor,

thanks for your help.

Okay, I thought the locks are record based. Then it is clear to me. I didnt found this information in any documentation.

Do you have any idea to bypass this problem?

Regards

Michael