ENQUEUE and DEQUEUE on DELETE ?

[kirankerudi]

Hello Experts,

Should I use ENQUEUE and DEQUEUE on DELETE dbtab statement ? The dbtab is within customer namespace.

Regards,

Kiran

[tapomay_sanyal]

Hi Kiran,

IMO you should use, as more than the reason its  standard or custom table the reason for good lock mechanism is to ensure sync in your application. If the same entry is expected to be used in other applications when you want to delete it should lead to unfortunate circumstances if proper lock mechanism is missing.

I hope usage of delete statements are used for deleting single entry at a time and not inside loop

----BR----

Tapomay

[kirankerudi]

Hi Tapomay,

I have to modify some primary key, which is not possible !!

So as a workaround, I will have to Read an entry, delete that particular entry, modify entry that was read, and reinsert the modified entries.

Correct me if I'm wrong, the entries that is being deleted and the entries that is being read at the same time must have same set of values in order to cause so called unfortunate circumstance. Right ?

Regards,

Kiran

[tapomay_sanyal]

Hi Kiran,

If you share bit more details like code fragment , can comment better.

However you can delete the entries once you have read it into local work area, change it and then push it to database table.

Sounds not a good idea too be honest , thus requesting to share bit more details.

---BR---

Tapomay

[abdul_hakim]

Hi Kiran,

Are you trying to delete the table entry in a standalone program or you are trying to delete the table entry from dialog transaction or trying to delete entry from existing report program??

Can you provide more context??????/

Thanks

Hakim

[Former Member]

You are essentially changing a record, so you should enqueue and dequeue, particularly if the table is used in a module pool.

Better to be safe than sorry.

Rob

[kirankerudi]

Hi Tapomay,

I couldn't find a better solution. Let me ask you one question.

If you have to modify an existing data in a table and in my case it's a primary key that needs a modification, how would you do it ?

Regards,

Kiran

[kirankerudi]

Yes definitely Rob. However these modifications have to be performed in a BADI implementation.

Was worried how this would have an adverse effects on any other programs.

Regards,

Kiran

[kirankerudi]

Hi Abdul,

Its within a BADI implementation. However concern was modifying a primary key !! AFAIK, Delete and re-insert will be only option.

Regards,

Kiran

[RaymondGiuseppi]

That is the reason to lock, you shouldn't allow this if somebody else is working on this record.

So raise an error if lock unsuccesful and insure every "maintain/create" program use the same ENQUEUE/DEQUEUE logic.

Hint: Here you "change" the primary key, so you should must enqueue both values, old and new.

Regards,

Raymond

[tapomay_sanyal]

Hi Kiran,

MARA has MATNR as primary key.

I just tested one line in our DEV it worked fine. (Dont try this !!! )

UPDATE MARA SET MATNR = '000000000000000001' where MATNR = '000000000000000041'.

It actually worked.

Still I am against such direct updates into database table.

---BR----

Tapomay

[kirankerudi]

Raymond, You mean to say that even on INSERT also I will have to ENQUEUE/DEQUEUE ?

Regards,

Kiran

[kirankerudi]

Hi Tapomay,

This will work. But as you said even I'm against direct updates to database table.

Regards,

Kiran

[tapomay_sanyal]

Hi Kiran,

If theres no other option then use UPDATE/SET and after it is done save the change record as SLG1 logs .This will let you or anyone else atleast know that from what value it was changed and in case of any problem situation you can reverse it.

For SLG1 logs you got to use few Function modules and usage of this is well documented over Internet.

Just a suggestion

---BR----

Tapomay

[kirankerudi]

Tapomay, logs are not required. This is an issue fix. A bug I must say. We are trying to fix it by correcting the table entry.

The process is very complex and I'm lazy to type in the whole process . So, I think I couldn't explain much better.

Regards,

Kiran

[kirankerudi]

Also, lets discuss this. Is UPDATE/SET a better option over DELETE and INSERT ?

Regards,

Kiran

[RaymondGiuseppi]

Yes, if you don't insure an unique key with a tool similar to range number or uuild, you have to insure that two users won't try to create same record.

Call a standard creation transaction, and check locks with SM12. Most transactions (those that don't generate the number at save event) will lock the not yet created record.

Regards,

Raymond

[tapomay_sanyal]

Hi Kiran,

If any such situation comes where I need to choose it is better to go with UPDATE SET , atleast no chance of corrupting or changing fields which I do not want

---BR----

Tapomay