BPS lock

[Former Member]

Hi everyone.

I'm having a problem that is confusing my mind. I tried dozens of filter configurations in planing level and in planning package, but nothing resolves a lock issue on BPS. It seems like no matter what restrictions I put on it, the entire cube data is always locked.

To try find out what could be happening, I created a simple cube, only with characteristics 0customer, 0mat_type, 0mat_group, 0calmonth and one key figure.

Then I created two planning levels, one filtering 0mat_type by value 'CA', and the other one filtering 0mat_type by value 'CS'.

After that I created one manual planing layout under each planning level. The layouts have all characteristics in lead columns.

If a user execute the layout under the first level, a second user receive the message "Data requested in planning area PL_AREA is locked by user XXX" when accessing the other layout under the other level.

Since the levels have different filters, it's not expected that one not affect the other?

I already tried to execute the report UPC_ENQUEUE_READ, but I always receive as result: __EMPTY_SELECTION__

Can anyone explain what may be happening or have any advise to solve this question?

We're in BW 3.5, SP 19.

Many thanks,

Henrique Teodoro

[Former Member · Accepted solution]

Hello,

If both users have __EMPTY_SELECTION__ in UPC_ENQUEUE_READ, then they will lock each other (they both have __EMPTY_SELECTION__ as selection...)

Just a question, do the filter values you put on your planning level (CA and CS) already exist in the masterdata of 0MAT_TYPE ? In other words, do you see these values when going to "Maintain master data" of 0MAT_TYPE?

rgds,

[Former Member · Accepted solution]

Hello, Jeoffrey.

I think the __EMPTY_SELECTION__ message in UPC_ENQUEUE_READ very strange too. Both users got the same result on this when accessing the levels.

For other BPS applications the result of UPC_ENQUEUE_READ is ok, listing the values selected for each characteristic. These applications don't have nothing special or different compared with the one having problems.

Related to master data for 0MAT_TYPE: yes, the values already exists.

Thanks for your tips.

Henrique

[Former Member · Accepted solution]

Hello,

I remember I already have had this __EMPTY_SELECTION__ case but it was in BI 7.0, and then I used T-Code RSPLSE instead of report UPC_ENQUEUE_READ.

The reason was that the restricion I made was on a characteristic that was not "Lock relevant".

I don't know if it can help you since I don't know where in BW 3.5 you can see/change this setting... but it is <i>maybe</i> a begin of answer to your problem...

Have you checked if this problem still occur if you put a copy instead of the original cube in the planning area?

Rgds,

For your info, here is a copy/paste of the online help about this topic in BI 7.0 :

<i><b>Definition</b>

When transaction data is requested in change mode, this data has to be locked exclusively for one user. The records to be locked are described in one selection table. A data record is locked by the selection table if the characteristic value in the data record is inlcuded in the selection for each characteristic in the selection table. If the selection table is empty, every data record is locked. It does not matter whether the data record exists in the database.

These locks are effected at InfoCube level. As a presetting, all characteristics in the InfoCube and the artificial characteristic '1KYFNM' (key figures are understood as values for this artificial characteristic) are relevant for locking.

<b>Use</b>

For many applications it is not necessary to make all characteristics relevant for locking. Therefore you may wish to determine just those characteristics that are relevant for locking. This means that the other characteristics are not used in the collision check, the selection tables for lock management are smaller and less complex. This is a very simple way of significantly reducing the load on the lock server.

<b>Dependencies</b>

If no characteristics are relevant for locking, the whole InfoCube is locked.

<b>Example</b>

In cost center planning you are using the characteristics 'Cost Center' 'Cost Element', 'Version', 'Fiscal Year'. If several users are planning for the same year and same cost elements, the characteristics 'Cost Center' and 'Version' are enough to ensure that selections for different users do not overlap. Determine only these characteristics as being relevant for locking.</i>

[Former Member · Accepted solution]

Hello, Jeoffrey.

You gave me a great clue, and I found the solution. On BW 3.5 exists a way to set the characteristic lock relevant, and this solved the situation.

Thank you very much. Your post was very helpful.

Henrique

[Former Member · Accepted solution]

Great!!!

Could you tell me how to reach this fucntionality in 3.5? I don't remember at all, and it could be usefull... who knows

rgds,

[Former Member · Accepted solution]

Hi,

The solution is described in Note 635244 - Locking transaction data in SEM-BPS.

It involves creating a table to maintain the characteristics lock relevant, and including a parameter in table upc_dark2.

Regards,

Henrique

[Former Member]

Hi Henrique,

This seems to be very unusual. I assume that the planning layouts are being exexuted from the GUI and no automatic function is attached to the layouts? Also in the layout definition you are not reading the other 0mat_type (which is not in the package) as a display column?

Regards,

SK

[Former Member]

Hi, SK.

I'm not using automatic functions or other values as display columns.

And the problem not seems to be related with the layout, since I created a simple function (to copy months) and the lock still happen.

Thanks,

Henrique

[Former Member]

This sure seems like a bug... did you look for OSS messages?

[Former Member]

Hi, Mayank.

I've already looked for OSS notes, but nothing apply to this situation. Also all modeling recomendations described in notes was take into account.

Thanks,

Henrique