topic Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE in Application Development and Automation Discussions

why to create a lock object when there is a FM ENQUEUE_E_TABLE

Former Member — Mon, 07 Jul 2014 15:56:58 GMT

Hi experts,

Need insight on why to create a lock object when there is already available Fm ENQUEUE_E_TABLE.

I understand there should be a very good reason for that. Please let me know you comments.

Thanks

Willi

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

former_member197622 — Mon, 07 Jul 2014 22:01:48 GMT

Hi Willi Robert

While you can use that FM to lock any table it has his limitations, with a "lock object" you can:

- specify the fields and secondary tables(with fields) to customize it

- select the type of lock

...

im sure there are more reasons... i dont wanna sound rude but please google it before posting, its a rule here and there is a lot of documentation out there...

check this link

http://help.sap.com/saphelp_nw70/helpdata/en/41/7af4c8a79e11d1950f0000e82de14a/content.htm

you will find the lock object EDEMOFLHT with a secondary table

Hope it helps

Regards

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

Former Member — Tue, 08 Jul 2014 02:16:27 GMT

Hi Willi

The FM which generated by Indivadul lock object can lock table at line item level(you can lock some lines, other lines are not locked.), but that FM only can lock table at table level.

Regards,

Archer

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

kiran_k8 — Tue, 08 Jul 2014 06:00:06 GMT

Archer,

Even using the FM ENQUEUE_E_TABLE we can lock the table at the key level using the parameter RSTABLE-VARKEY.

K.Kiran.

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

Former Member — Tue, 08 Jul 2014 16:07:50 GMT

Hi Kiran,

That's true we can lock objects a row level with standard FM as well, and thats why I have raises this question we can have same functinality with both the things.

One reason I understand that we can specificaly decide on which key field we want to lock or a combination as well but is this the reason they created an object ?

the other reason I know is if you use lock object it checks only if table is locked for the same locked object, but is we use standard FM even if you have opened it with SM30 it will give a runtime after waiting for a while.

Please provide you insight.

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

kiran_k8 — Wed, 09 Jul 2014 05:54:45 GMT

Robert,

To my knowledge,whether it is ENQUEUE_E_TABLE or Custom Lock Object a table can be locked at the record level only using Primary keys.But through Custom Lock Object we can extend the lock even to Foreign keys related to secondary tables.Let's see what experts get to say on this.

K.Kiran.

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

Former Member — Wed, 09 Jul 2014 06:35:00 GMT

Hi robert,

To lock any transaction or table or item level while using same to other user. the purpose of this function module to lock table on key based.

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

Former Member — Thu, 10 Jul 2014 18:43:39 GMT

Not much satisfactory answer yet , I was waiting for some expert to comment on , will wait for one more day and the close the thread.

Thanks

Re: why to create a lock object when there is a FM ENQUEUE_E_TABLE

SuhaSaha — Thu, 10 Jul 2014 20:05:28 GMT


To my knowledge,whether it is ENQUEUE_E_TABLE or Custom Lock Object a table can be locked at the record level only using Primary keys.

Not entirely correct

The golden rule with SAP locking mechanism is based on "logical" locks and not "physical" locks. In this mechanism the most important role is played by the lock argument (SEQTA-GARG), the lock requests are checked against each other using this lock argument.

Since key fields help you to identify a unique record of a table, you can use them to build the lock argument. I can also create a UUID, GUID, hash key et al. using the key fields and pass it as a lock argument.

In fact there is no correlation between the table & the lock argument, you can give any arbitrary argument, the lock module will still be able to lock it (unless there is a lock collision, of course )

Now back to the OP's question. If you check the lock object E_TABLE, you will find that TABNAME & VARKEY are passed on as the lock argument. So you have to manually build the VARKEY and pass it on. But if you use more specific lock objects (e.g., ESFLIGHT), you don't have to think about the argument. The lock object FMs do it automatically for you.

I am not sure if i could convince the OP of "why" he should not use the generic E_TABLE lock object. IMHO there is no answer to the "why", if it is used for simple locking mechanism then E_TABLE is sufficient. But if you wanna use it for more fancy stuff (e.g., secondary table) in that case you have to use the specific lock objects.

I would always use a more specific lock object if available, then using the generic E_TABLE.

Br,

Suhas