topic Re: Using lock object in Application Development and Automation Discussions

Using lock object

Former Member — Sat, 17 Oct 2009 20:30:09 GMT

HI ,

I have tables which are updated from FM .

the table have user context .

my question is if i need to use lock object if i dont create maintenance view for the tables ?

Or in other words when to use it and when not ?

Regards

JOy

Edited by: Joy Stpr on Oct 18, 2009 8:29 AM

Re: Using lock object

matt — Sun, 18 Oct 2009 12:21:00 GMT

If there's any possibility of two users trying to update the same record at the same time, then you need to use locking.

matt

Re: Using lock object

Former Member — Sun, 18 Oct 2009 14:00:29 GMT

When your tables ared used in a user context you should use proper locking.

When you say that the tables are updated via function modules check the function group of these function modules.

Most probably the function group will contain function modules to logically lock the table via enqueues functions.

You can build in these enqueue functions in your program.

Wim

Re: Using lock object

Clemenss — Sun, 18 Oct 2009 14:32:36 GMT

Hi Joy,

my 2 cents added:

The standard maintenance view uses a generic lock object locking the whole table - as long as a user edits the table using the maintenance view, no other user can change the table using this maintenance view.

If you create a table-specific lock object, you can specify a key for locking so that speific records are not changed at the same time.

There is ample documentation on lock objects.

Regards,

Clemens

Re: Using lock object

Former Member — Sun, 18 Oct 2009 17:05:54 GMT

Hi Joy,

Well to be specific I had used Locking the object in HR module, so i would like to explain based on that.

HR modules have many views in a transaction...and they display data from tables.

now when we change data...at times it is necessary that the data must not be changed at all.

in such scenarios, we lock the object, means no changes can be done.

as 1 friend has rightly mentioned abt enqueue function.

actually theres a function module for enqueue...when u need to make any changes to the data...

u shud 1st enqueue that particular record, so that no one else can edit it, or work on it....after making necessary changes, u then dequeue it...so that it becomes accessible for editing.

so, basically locks, as name suggest can be used to prevent editing.

either temporarily till u r making changes to it....or for a long time...

but the locks can also be removed by coding...

Hope this information helps u

Regards,

Radhika

Re: Using lock object

matt — Sun, 18 Oct 2009 18:07:38 GMT

Moderator message The use of abbreviations like "abt" instead of "about" is suitable when you send a text message, or when you use IM. It is not suitable for a professional forum. Please spell words out in full. Not everyone on these forums is a fluent English speaker and the use of abbreviations doesn't help - and it is lazy.

matt

Re: Using lock object

Former Member — Sun, 18 Oct 2009 18:13:45 GMT

sorry about it moderator...would take care next time...

Re: Using lock object

matt — Sun, 18 Oct 2009 18:15:05 GMT

good.

Re: Using lock object

Former Member — Sun, 18 Oct 2009 18:25:39 GMT

Can you please do me another favour as well in telling to also not use the same type of sms txt spk in the same places and in the same threads as your same answers...?

Re: Using lock object

Former Member — Sun, 18 Oct 2009 18:44:24 GMT

HI Matt,

what should i do in bulk delete of users ?

the use case is that i have option to delete bulk of users i,e, delete from table Z.... ?

one option is to do loop but it's not good from performance aspects so what u suggest ?

Regards Joy

Re: Using lock object

Former Member — Sun, 18 Oct 2009 18:54:46 GMT

Hello Sir,

How can I tell someone to stop using sms type text...I was told by moderator, I corrected myself.

It would be good if moderator tells that person directly.

Re: Using lock object

Former Member — Sun, 18 Oct 2009 19:44:27 GMT

> It would be good if moderator tells that person directly.

That person told us that they know you, quite well...

Re: Using lock object

Former Member — Sun, 18 Oct 2009 19:59:01 GMT

As this is a z-table updated from a z-FM, why don't you try locking the use of the FM (or transaction to call it) while it is being called by another user.

There are some SAP standard transactions which work in this way. Take a look at STRUST for an example.

If you choose a transaction code option and it is a report type transaction, then remember to call FM AUTHORITY_CHECK_TCODE in the report as well...

Perhaps if you give clearer information upfront when asking the question, then it will save folks a lot of guess work, if they read the question clearly.

Cheers,

Julius

Re: Using lock object

Former Member — Sun, 18 Oct 2009 20:08:27 GMT

oh that is strange and weird.....

but i can say for sure i dont know that person...100% sure.....

basically i dont know anyone from sdn forum, i just come here to give answers and to find out answers to my questions.

I feel this discussion is going away from the actual topic. Sir, you can warn that person, since you have the authority. I dont know that person. I cant tell & I wont tell. Sorry.

Re: Using lock object

Former Member — Sun, 18 Oct 2009 20:19:09 GMT

> I feel this discussion is going away from the actual topic.

True. I will hand it over to SAP to investigate that user further.

Re: Using lock object

Former Member — Sun, 18 Oct 2009 20:29:03 GMT

Fine. Thank you very much sir.

I wonder how can someone just say that they know me quite well, whereas i dont know that person at all.

Re: Using lock object

Former Member — Sun, 18 Oct 2009 20:38:49 GMT

Yes, even I am finding it strange that the person is sending me mails then.

Please change your password to be safe.

Cheers,

Julius

Re: Using lock object

Former Member — Sun, 18 Oct 2009 21:13:48 GMT

> the use case is that i have option to delete bulk of users i,e, delete from table Z.... ?

An after-thought --> obviously there is some program using this table as well...

Why don't you change the program to check an authorization object and then control the "entries" via the assignment of a role which includes with object with appropriate authorization fields?

This way you can re-use the same object with different field values, and use your FM in a modularized way - instead if using this lock workaround to treat a symptom of the design problem.

Cheers,

Julius