FM 'VIEW_ENQUEUE'

[former_member182371]

Hi,

i´m using FM

'VIEW_ENQUEUE'

and i need to lock only certain entries in the view and not the whole table.

How can i do it?.

Best regards.

[Former Member]

Hi,

Check this if it suits ur requirement,

http://www.sapdevelopment.co.uk/dictionary/lock_enqueue.htm

Thanks & Regards,

Judith.

[christian_wohlfahrt]

Hi,

import parameter ENQUEUE_RANGE has to be set to 'X' and with table parameter SELLIST you can define selection criteria for your partial lock. I hope short text of field definition of structure VIMSELLIST will give you a hint of correct filling.

Regards,

Christian

[former_member182371]

Hi,

i´ve been trying with the following code:

• first key field

i_sel-operator = 'EQ'.

i_sel-value = pnumde.

i_sel-viewfield = 'NUMDE'.

i_sel-and_or = 'AND'.

APPEND i_sel.

CLEAR i_sel.

• second key field

i_sel-operator = 'EQ'.

i_sel-value = pkunnr.

i_sel-viewfield = 'KUNNR'.

APPEND i_sel.

CLEAR i_sel.

call function 'VIEW_ENQUEUE'

exporting

ACTION = 'E'

ENQUEUE_MODE = 'E'

view_name = 'Z_V_DEVOLUCION'

ENQUEUE_RANGE = 'X'

TABLES

SELLIST = i_sel

EXCEPTIONS

CLIENT_REFERENCE = 1

FOREIGN_LOCK = 2

INVALID_ACTION = 3

INVALID_ENQUEUE_MODE = 4

SYSTEM_FAILURE = 5

TABLE_NOT_FOUND = 6

OTHERS = 7.

if sy-subrc <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

endif.

but unfortunately the lock affects the whole table.

Any suggestion?.

Best regards.

[christian_wohlfahrt]

Hi,

yes, you can debug FORM fill_d0100_field_tab.

It's probably the fastest way to figure out what's happening.

Christian

[former_member182371]

hi,

i´ve checked it out and the flow of the program doesn´t pass through FORM fill_d0100_field_tab.

Regards.

[christian_wohlfahrt]

Ok, next try.

In view_enqueue, about line 118 is a statement:

ELSE. "view

here your version should go.

Immediately inside the loop routine:

fill_tabkey

is called. Inside client field handling is programmed -> maybe that's the point: implicit client is always selected first - if you don't specify the client, you don't have the key fields 'from the left' (similiar to the table range scan questions in selections: you have to define all key fields from the beginning, otherwise ranges of valid keys will be used).

Then

CHECK enqueue_range NE space.

can be found. Afterwards preparation of select statement is done.

But currently I bet on client, try this out - otherwise have a look at 'LOOP AT sellist' in form 'fill_tabkey'.

Regards,

Christian

[Former Member]

Just a thought, why don't you create your own enque object for the Z table and use that instead of the generic one?

[christian_wohlfahrt]

Hi,

unfortunately we don't have remote debugging, otherwise I would have seen the difference:

do we talk about a table Z_V_... or a view?

In last version I asumed view - and then Z-enqueue object is out of scope.

Regards,

Christian

[former_member182371]

Hi, the reason for not using a lock object for the ztable is that i´ve developed a report that via FM 'VIEW_MAINTENANCE _CALL' allows the user to insert or update the table in question and thus it must be in the view that the lock must be set.

Regards

[Former Member]

I apologize for not paying attention to the details. Thanks for the clarification. I will check if and how record level locking is possible.

[former_member182371]

Hi Christian,

we´re talkung about a view.

Z_V_DEVOLUCION is a maintenance view that contains table ZDEVOLUCION.

regards-

[Former Member]

Hi Calsadillo,

Just FYI, it doesn't matter whether you lock the table or the view, as long as the locking strategy you use is <b>CONSISTENT</b>.

When you do a lock, it doesn't actually lock the object (from the database point of view) it just sets an entry in a table that says: Table X, Key Y is locked. Then if another program tries to lock the object then it checks the table, if the entry is found then you can't lock it.

Thus in your situation if you have another program which updates the Z table directly and not via the view (and locks the table), and the first program locks the view, both will be able to update the data at the same time.

Therefore, for simplicity's sake (and given that the view locking process is causing you grief) I would just lock the table. It makes more logical sense anyway.

Hope that helps.

Brad